[LiivaneLord]

http://liivanelord.planet.ee/viking/?1=6&2=2&3=34&4=11&5=45&6=46&7=47&8=9&9=14&10=16&11=5&tabel=on&sagedus=1&vt=Vaata

See tabel täispikana laeb väga aeglaselt, vähemalt 10 sekundit kulub enne, kui kogu leht on laetud. Selle vältimiseks võtsin kasutusele vaikimisi piiratud tabeli suuruse näitamise, kuid kas kogu tabelit annaks kuidagi kuvada nii, et see oleks väiksem koormus serverile ja kasutaja arvutile ning avaneks kiiremini?

See on loodud puhtalt tabeli põhjal, andmed on andmebaasis kujul loosimise number, I, II, III, IV, V, VI, lisa1, lisa2, õnnenumber + tabamuste väärtused.



Kood on pikk, aga lühidalt kokkuvõttes tulevad andmebaasist andmed kujul $andmed_numbrid[nr]. Kui $andmed_numbrid[nr] kattub pileti numbriga, siis number on punane või roheline. Sedasi iga numbri kohta. Sedasi iga ühtivuse korral suureneb põhinumbrite või lisanumbrite hulk ning vastavalt sellele valitakse andmebaasi teisest (süsteemi)tabelist õige vastavate tabamuste hulk valitud numbrite hulga kohta, korrutatakse see numbrite tabelis kirja pandud tabamuste väärtustega läbi ja sellest kujuneb võidusumma.
See toimub kogu tabeli ulatuses, vaatamata sellele, kas tabel on avatud täielikult või osaliselt. Aga kui tabel on avatud osaliselt (100 viimast loosimist), siis avaneb tabel alla 3 sekundiga.

On võimalik midagi muuta või asjale teisiti läheneda? Kood ise, mis tabeli loob, on lühidalt:

[spreiii]

Ilmselt on siinkohal probleemiks just vastav SQL kood või siis meetod kuidas neid andmeid hiljem (loop'is) töödeldakse.

[andrusny]

Kui ridu tuleb üle saja-kahesaja, siis peaksid tulemuse vist ikkagi lehekülgedeks jaotama. See teeks ju lehekülje mõttetult pikaks, kel vaja, kül see õige lehekülje avaks. Mitmest reast üldse jutt käiks?

[LiivaneLord]

andrusny, tiba üle 1000 rea. Peab vist lehekülgede peale mõtlema jah.

[p2tu]

No 1000 rida html'is laebki aeglaselt. Siin oleks ainuke lahendis mingi preload jqueryga vms. Lihtsam on sul teha lehed 100 kaupa.

[2ndalpha]

Ega Sa mingeid stiile jQueryga külge ei pane. Nii suure DOM puu läbikäimine võtab kaua aega.
Igasugu muude spekulatsioonide vältimiseks soovitan vaadata mille peale täpsemalt aeg kulub: http://tools.pingdom.com/fpt/

[LiivaneLord]

p2tu, ok, teen siis mitu lehte.

[mikk150]

p6hjus miks kaua laeb on andmete k2ttesaamine aeglastelt hdd delt. midagi sinna teha ei saa. olen ise ka staatilist tabelit genereerinud, kuna nii on kiirem

[2ndalpha]

[LiivaneLord]

mikk150, eks mul see loop on ka üsna mahukas. Andmed tuleb andmebaasist võtta, kõiki numbreid võrrelda kasutaja poolt sisestatud numbritega, võrrelda seda hulka andmebaasi teise tabeliga, leida tabamus ja võidusumma. Vastavalt sellele luua tabel. Vaatan koodi ka täpsemalt üle, kuidas seda lühendada, kuna praegusel juhul on liiga palju ebavajalikku CSS-i, mis on by default brauseri poolt valitud.

Kui kasutada veel tabeli värviliselt kuvamist, siis on asi eriti hull. Korra tuli isegi planet.ee poolt teade, et mingi limiit on ületatud ja pean maksma lisa ning leht on blokeeritud. Rohkem pole õnneks tulnud ja leht ikkagi avanes uue refreshiga.

[spreiii]

Ehk oleks võimalik sobivad vastused juba ühes SQL Query's kätte saada, et ei peaks näiteks iga rea korral uuesti andmebaasist midagi küsima (juhul kui hetkel nii on)?

[LiivaneLord]

[spreiii]

Uurin veel koodi, kuid esimese rea kohta võin öelda, et praegusel juhul on võimalik SQL Injection.
Uuri veidi: http://en.wikipedia.org/wiki/SQL_injection
Probleemne koht täpsemalt siis: $_GET[nt]

[LiivaneLord]

spreiii, on nii õige?: (Unustan alati sellised asjad ära. )

[mikk150]

2ra kasuta " m2rki, kasuta php koodis ' m2rki. kiirem

[spreiii]

mysql_real_escape_string on jah üldjuhul piisav kaitse.
Edit: ideaalne oleks veel muidugi kontrollida, kas tegu on numbriga:

[LiivaneLord]

spreiii, andmebaasi sisestamise jaoks on mulle õpetatud kasutama htmlspecialchars().

mikk150, ee, aga ülakoma kasutades võtab PHP muutujat kui ennast, aga mitte muutujat, kui selle väärtust. Ehk siis kui $muutuja=1, siis echo "$muutuja" kirjutab "1", aga echo '$muutuja' kirjutab "$muutuja". Või sain ma sust valesti aru?

[karu]

[LiivaneLord]

Ma ei tea, olen harjunud jutumärgiga.

[andrusny]

See ' pole ülakoma vaid ühekordne jutumärk. Ülakoma on see ´ või vähemasiti mina tean seda selliselt.

[p2tu]

1000 rea jaoks päringu optimeerimine ei anna sul soovitud tulemust, kuvamine kiiremaks ei muutu.
Probleem ei ole sul päringus vaid kuvamises endas. Päring ise käib ilmselt 0.0... sekundit.
Seda saad eraldi vaadata, kiire google - http://stackoverflow.com/questions/8156095/calculating-time-of-a-query-php-mysql

See 1000 rida lihtsalt html'is veebilehele kuvatakse aeglaselt muudel põhjustel nagu ka ülevalpool mainiti - brauser ise, html keel, hdd kiirus, netikiirus (suhtlus serveriga) jne.

[Redikate]

1000 rida on nii minimaalne andmebaas, et seal küll SQL'i taha midagi ei jää, veelvähem mingi faili lugemise taha. Nagu p2tu ütles, siis päring ise võtab ilmselt 0.0.. sekundit ja selle taha sul küll midagi ei jää.
Samamoodi on su while täiesti basic ning seegi ei võta peaaegu üldse aega, niiet aeglus peab ikkagi olema kinni juba html'i näitamises.

[2ndalpha]

Nagu ma enne juba ütlesin, siis kõige lihtsam on mõõta kuluvat aega http://tools.pingdom.com/fpt/ abil
Muidugi võib ka Firebugi või Chromega seda teha.
Siis näeb kas asi jääb serveri, allalaadimise, renderdamise või muu taha.

[Ho Ho]

Olen üsnagi kindel, et su probleem on selles koodireas:

if(in_array($andmed_numbrid[$väärtus], $array_numbritest)){

Nii palju kui aru saan on tegu üsnagi kuluka operatsiooniga. Eeldades, et too $array_numbritest on samuti tuhatkond rida tehtakse sul seal umbes pool miljonit võrdlust per page load. Piirates kuvatavate ridade arvu 1000 pealt 100'le vähendaks selle ainult 1M pealt 100k peale mis kokkuvõttes ei ole ikkagi normaalne efektiivsus.

Lahenda asi SQL'is üheainsa päringuga, saad oluliselt kiirema tulemuse.

[LiivaneLord]

Ho Ho, $array_numbritest on kasutaja poolt sisestatud numbrid, mida on 1-11. Kuna andmebaasis on natuke üle 1000 rea, siis tähendab see 1000*7*11 võrdlust.

Aga tundub, et jääb jah htmli näitamise taha kogu see tabeli näitamine. Võtsin lehe source, laadisin üles ja laeb samamoodi kaua, võiks öelda, et mõned sekundid ehk kauemgi. Tegelikult minu küsimus oligi pigem selles, et kas antud leht on mõistlik luua tabeli lahtritena või kuidagi muudmoodi. Aga ega vist paremat lahendust poleks ka, kui ainult piiramine ...

[Ho Ho]

Mmm, my bad. Üle rea lugedes jäi mulje, et see on läbi ajaloo kõigi välja loositud numbrite hulk.

[LiivaneLord]

Ho Ho, see on jah while-statementis sedasi, et kõigepealt on uusim loosimine, mis hetkel on 1027. Kontrollib, kas I on esindatud numbrite seal. Kui on, siis punane, kui mitte, siis tavaline tekst ja lahter. Ja sedasi kõigi 7 numbriga I-VI, lisa1,lisa2, mis ühel loosimisel on välja loositud. Ja järjest nii kõigi loosimistega. Ja see kõik peaks teostuma minu puhul ühe päringuga? $sql_numbrid=mysql_query("select * from $viking order by nr DESC limit ".mysql_real_escape_string($_GET[nt]));

[2ndalpha]

Kui Sa CSS-i ega javascripti külge ei pane, kas siis on ikka aeglane?

[LiivaneLord]

[Ho Ho]

Miks sul seal nii röögatult palju tühje tabeliridu-tulpasid on?

Samuti saaksid juba puhtalt faili tirimise pealt päris korraliku kokkuhoiu kui sinna dropdownidesse ei lahmi kõiki 1000+ valikut vaid näiteks 1-10 ning ülejäänud mingi mõistliku sammuga. Veel parem kui teed selle lihtsalt teksti sisestus kastiks. Veel suurema kokkuhoiu saaksid kui kasutaksid normaalset CSS'i mitte ei kleebiks stiili igale tabeli lahtrile ühekaupa külge. Hetkel on sul too fail pea 1.5 MB puhast teksti


Olen päris kindel, et hetkeseisuga on probleemiallikas just see inline stiili määramine korrektse CSS'i kasutamise asemel.
[edit]
See ei ole CSS'i kasutamine (üksainus rida tabelist, reavahetused minu poolt näitamaks kuivõrd röögatult suure raiskamisega tegu):

[mikk36]

Kui aeglaselt teil need siis laevad?

Spoiler

[Redikate]

Tekib siinkohal sama küsimus. Minul laeb leht 507ms'iga mis üldiselt on nagu piisavalt kiire või nii.

Spoiler

[Ho Ho]

Lükake see "Näita kogu tabelit" linnuke ka ikka sisse.

[Redikate]

[andrusny]

Neti kiirus siis järelikult sul omal madal kogu tabel ja värvilisena, siis tuli andmeid serverist üle 1,5M kuna mul ka aeglane ühendus, siis läks aega suht , et siis kokkuvõttes neti kiirus jääb aeglaseks vist. Mis seal üldse selle pea 2M välja annab? Pilte ju pole ning 1000rida arve ei tohiks ometi nii palju mahtu võtta. Või võtab?

[Ho Ho]

[andrusny]

Jah uurisin ise ka hetkel koodi

[LiivaneLord]

mikk36, index2.php on kärbitud natuke, kuskil tuli väike aps ka vahele, et tabamust ja võidusummat ei näita, aga ma muudan CSS-i. Inline kaotan ära.

Edit: Tegin muudatused ära ja tabel muutus poole kiiremaks. Varem laadis 12 sek, nüüd 6 sek -> http://liivanelord.planet.ee/viking/index3.php?1=6&2=2&3=34&4=11&5=45&6=46&7=47&8=9&9=14&10=16&11=5&tabel=on&vt=Vaata Klikake siis kindlasti sellele lingile, kuna see on index3.php, et teil ei tekiks segadust.

CSS tõin faili etteotsa. Hiljem vaatan üle, kas on veel midagi vaja ja siis peab järgi proovima, ega vigu pole sisse sattunud.

NB! Vaikimisi keelasin ära täispika tabeli näitamise, kui pole küpsised salvestatud. Kogu tabeli nägemiseks vali "Näita kogu tabelit" ja vajuta Vaata.

EDIT2:

[Lordlesta]

[LiivaneLord]

Nonii, tegin eile ja täna plaanilisi muudatusi lehel ning muuseas näppisin ka CSS-i. Mida arvate nüüd tabeli lähtekoodist? -> http://liivanelord.planet.ee/viking/?1=16&2=27&3=24&4=28&5=20&6=23&tabel=on&vt=Vaata

Võrreldes ühe varasema versiooniga on laadimine poole kiirem umbes. Väga hästi mõõta ei saa, kuna nüüd on mul megase neti asemel 5 mega, aga enam-vähem on aru saada -> http://liivanelord.planet.ee/viking/index3.php?1=16&2=27&3=24&4=28&5=20&6=23&tabel=on&vt=Vaata

Javascripti osas muudatusi ei ole teinud, ei oska. Javascript üldiselt on nii raske minu jaoks.

[kuunar]

Loto on siin foorumis valus teema.

[LiivaneLord]

[Redikate]

http://jbrantly.github.io/bigtable/ => miljon rida.
http://jsfiddle.net/ThinkingStiff/gyaGk/ => päris kiire 1000 rida

Kuid üldiselt soovitan jagada lehekülgedeks + sortimine + search.

[LiivaneLord]

Spoiler

LiivaneLord kirjutas:

Redikate, nagu ma aru saan, siis see tabel luuakse javascriptiga. Minul on aga andmed andmebaasis ning lehe laadimisel toimub alati erinevate numbrite kokkuliitmine ning statistika lubamisel arvutab nende numbrite esinemissagedus jms. Ma ei kujuta ette, kuidas antud tabel javascriptiga valmis vorpida. :S Algul tegin statistika püsivaks ehk uute andmete sisestamisel tehti see kalkulatsioon kohe ära ja lisati andmebaasi, aga hiljem lisasin veergude kaupa eraldi statistika loomise võimaluse ning siis kadus asja mõte ära. Lehe laadimisaega see praktiliselt ei muutnud. Olen otsustanud, et lehekülgi ma ei tee. Sellel ei ole praktilist vajadust. Vaikimisi on nähtav vaid 100 viimast rida ja 90+% juhtudel sellest peaks piisama. Kogu tabel on vaid lisavõimalus ning ka praegu ei kulu selle laadimiseks väga kaua aega.

Nii, tegin numbrite tabeli ka javascripti versioonis. Server loob php-ga javascripti, kus on array "nr", milles on subarrayd, kus iga subarray kohta on kogu info loosi kohta (ehk andmed andmebaasis). Teine array on "tdstiil", mis sisaldab töödeldud infot (tabeli välja stiil, tabamus, võit jms). Ma ei tea, kas see oli õige viis seda teha, kuid see oli minu esimene nägemus asjast.

Javascriptiga loodud index4.php: http://liivanelord.planet.ee/viking/index4.php?1=16&2=27&3=22&4=7&5=20&6=36&7=30&tabel=on&vt=Vaata
Tavaline index.php: http://liivanelord.planet.ee/viking/index.php?1=16&2=27&3=22&4=7&5=20&6=36&7=30&tabel=on&vt=Vaata

Nagu näha, siis Javascriptiga versioon laeb vaat et aeglasemalt isegi. Javascripti koodis on kindlasti üleliigseid ridasid, kuna spikerdasin teiste koodide pealt, et aru saada, kuidas HTML koodi loomine javascriptiga käib.

[Redikate]

index4.php: 608.39 ms
index.php: 429.87 ms

Üldiselt ma ei näe milles probleem. <1s on liiga pikk loading time? :p

Oleks mul aega krt, prooviks ise ka seda tabeli näitamist teha.

[mikk36]

Eks osa laadimise aja pikenemisest on põhjustatud ka suuremast failist, mida alla on vaja laadida (382 KB vs 463 KB)

[LiivaneLord]