Keskustelu: Nettisivujen teko: Suurten kävijämäärien huomioon ottaminen

Tietääkö kukaan kirjaa, webbisaitteja tai jotain missä on infoa miten suuret kävijämäärät pitää ottaa huomioon koodissa. Antakaa myös omakohtaisia kokemuksianne. Varmasti kaikille hyödyllinen topic.

Optimoi koodin, ettei se vie paljoa suoritusaikaa / vaadi servukoneelta liikoja, myös tietokannan osalta ja yrittää pitää lähetettävän datan määrän mahdollisimman pienenä, jotta kaistaa riittäisi useammille.

[IHMO]
Purkat php-koodit eivät niinkään kuormita palvelua verrattuna huonosti suunniteltuun tietokantaan. Kävijämäärien noustessa ja tietokannan koon kasvaessa tietokannan optimoitu rakenne sekä oikeaoppiset tietokantakyselyt ovat mielestäni kaiken perusta. SQL-kyselyiden hidastumisesta se ensimmäisenä alkaa heijastumaan latausaikoihin.
[/IHMO]

Kattelin uutta palveluasi ja tykkäsin. Heti ensimmäisenä kuitenkin pisti silmään sivun alareunassa olevat linkit vanhemmille sivuille ([1][2][3]...[10]). Tästä voisin päätellä, että linkkien haku tapahtuu kyselyllä joka pseudona näyttää suurinpiirtein tältä:

$offset = $_GET['offset'];
SELECT * FROM linkit ORDER BY id DESC LIMIT $offset, 25

Juuri tämänlaisen kyselyn olen huomannut erittäin huonoksi. Etusivu latautuu kylläkin nopeasti, samoin muutkin alkupään sivut, mutta sen jälkeen kun kysely alkaa näyttämään suraavalta

SELECT * FROM linkit ORDER BY id DESC LIMIT 25000, 25

alkaa tietokanta nöyrtyä, sillä nyt kanta hakeenkin jo tavallaan 25 000 riviä dataa, vaikkakin niistä näytetään vain 25 riviä. Eli käyttäjälle ei kannata tarjota linkkejä kuin juuri ehkä kymmenelle ensimmäisille sivuille.

Myös ohjelmointiputkassa näyttää olevan linkki ihan keskustelujen alkupäähän. (PHP_alueella tällä hetkellä: Sivut: 1 2 3 4 5 ... 122). Tosin täällä putkassa tuota hitautta ei huomaa, kun nämä ovat muutenkin niin hitaat sivut :) Mutta samalla Antille vinkiksi, että on ihan turha tarjota linkkiä tuonne sivulle 122. Sen sivun lataaminen kuormittaa aivan turhaan palvelua.

Palvelimen tehot on suuressa roolissa sivustoilla joissa on paljon kävijöitä.

Kuten ajv mainitsi niin tietokannan rakenne on suuressa roolissa. Isoissa tietokannoissa tulee olla hyvin suunnitellut indexit ja viite-eheydet (cascade-malli).

Tietoturvasta minun on varmaan turha tolkuttaa, ethän tee kyselyitä tyyliin "SELECT * FROM taulu WHERE id = {$_POST['id']}" ethän?-)

Isoissa käyttäjämassoissa on havaittavissa viittä perustyyppiä olevaa käyttäjää jotka ovat:

80% peruskäyttäjiä, lukevat ohjeita ja haluavat käyttää sivua oikein

8% hutilokäyttäjiä, syöttävät päivämäärän "04/04/04" ja kiroilevat kovaan ääneen vaikka ohjeet sanoo "syötä päivämäärä muodossa pp.kk.vvv"

4% oikeita palikoita. Kahlaavat ohjeita ja tekevät mielestään ohjeiden mukaan. Kun palvelu herjaa, tulevat he kovaan ääneen huutamaan sähköpostiin tai irc-kanavalle koko palvelun suolenmutkasta reväistyksi.

6% ilkeitä käyttäjiä, syöttävät päivämäärinä "1' OR [tähän haittakoodia]" ja yrittävät tonkia porsaanreikiä ihan vain siksi että virtuaalipippeli kasvaisi

2% ûber-wannabee-1337-HTML-PHP-pr0sk1ll3d kävijöitä joita ei miellytä mikään. Nämä käyttäjät mm. arvostelevat html-lähdekoodia, kertovat sinulle miksi sinun ei tulisi käyttää edes käyttämisen kannalta helpottavia javascript-koodeja ja pasteilevat validaattorilinkkejä foorumeille yms. vain että muut heidän kaltaisensa voisivat jatkaa urakkaa kun heiltä palaa hihat sivuston ylläpitäjän passiivisuuteen "heidän valittaessa aiheesta".

Siinä olisi melko tarkkaan sopan ainesosat, nyt sinun tulisi löytää kattila missä ainakin ensimmäiset 92% aineksista pysyisi kuosissa.

Eli se mikä tuntuu sinusta ihan loogiselta, ei sitä välttämättä ole. Tee ennemmin virhesietoista koodia kuin että rajaisit käyttäjät yhteen tiettyyn formaattiin.

Lisäksi ei kannata yhtään väheksyä ohjeita, mutta ei kannata tehdä 102 sivuista manuaaliakaan palvelun käyttämiseksi. FAQ on hyvä luoda heti, mielellään puoliautomaattinen että voi jättää kysymyksiä jos sellaisia ilmenee. Bugit kannattaa ilmoittaa käyttäjille selkeästi, ei kuitenkaan liian informatiivisina (kiitos 6%). Käyttäjät yleensä bugin ilmestyessä tulevat kertomaan mitä he tekivät ja missä.

Ja kaikista tärkein: älä rajaa sivustoa selaimelle X, resoluutiolle Y tai millekään vastaavalle. Mieluummin yksinkertainen semantiikka joka toimii kaikilla, kuin pomppivat porot jotka juoksee ruudun ympäri jos selain on IE ja resoluutio 1024x768, kuun vaihe on puolikuun paikkeilla ja hiiren kursori painikkeen Z päällä.

Tulipa pitkä viesti, toivottavasti oli jotain apua :)

Jos tietty paljon tietokantakyselyitä sisältävä sivu ei alati muutu, tietoja ei kannata joka kerta hakea tietokannasta vaan ne on viisasta pistää talteen erilliseen tiedostoon, jonka voi suoraan liittää sivulle. Vain silloin tiedot haetaan uudestaan, kun ne ovat muuttuneet. Tämä on mainio parannus sivujen nopeuteen, jos tietokanta tuntuu olevan pullonkaulana.

Antti Laaksonen kirjoitti:

Jos tietty paljon tietokantakyselyitä sisältävä sivu ei alati muutu, tietoja ei kannata joka kerta hakea tietokannasta vaan ne on viisasta pistää talteen erilliseen tiedostoon, jonka voi suoraan liittää sivulle. Vain silloin tiedot haetaan uudestaan, kun ne ovat muuttuneet. Tämä on mainio parannus sivujen nopeuteen, jos tietokanta tuntuu olevan pullonkaulana.

Minusta tuo on kyllä aika paha purkka-ratkaisu. Eihän oikein suunniteltu tietokanta voi olla pullonkaula? Jos on, niin silloin jotain on tehty väärin :) En tiedä, mutta veikkaisin, että esim. IRC-gallerian ylläpito ei ole moiseen sortunut.

Tai no, voihan tietenkin olla niin, että palvelimen resurssit eivät vain yksinkertaisesti riitä pyörittämään ylikuormitettua tietokantaa (kuten ilmeisesti INT2000:lla). Silloin lienee oikea ratkaisu miettiä uutta palveluntarjoajaa.

Minulle ei ainakaan tule mieleen, mitä haittaa tuommoisesta voisi olla. Aina on hyvä juttu, jos säästyy tekemästä samaa työtä useasti. Jos esim. tiedossa on luku 143, ohjelman ei kannata laskea joka kerta 1222791080775407:n seitsemättä juurta. Luulenpa, että hyvästä suunnittelusta huolimatta yksi jos toinenkin sivu alkaa hidastua, jos käyttäjiä on paljon, tietokanta on suuri ja kyselyt ovat monimutkaisia (Int2000 on tietenkin luku sinänsä...).

No meneehän taas offtopiciksi, mutta menköön :)

Antti Laaksonen kirjoitti:

Jos esim. tiedossa on luku 143, ohjelman ei kannata laskea joka kerta 1222791080775407:n seitsemättä juurta.

Tämä on aivan totta, mutta ei ole mielestäni suoraan sovellettavissa tietokanta-sovellukseen. On eri asia laittaa luku 143 talteen muuttujaan, kuin tallettaa se tiedostoon. Minun mielestä tietokoneen tulee tehdä sille tarkoitettu työ. Tietokannan työ on säilyttää dataa ja antaa sitä tarvittaessa ulos. Jos työtä aletaan tehdä tietokannan puolesta, niin minusta tehdään aivan turhaa työtä.

Antti Laaksonen kirjoitti:

Minulle ei ainakaan tule mieleen, mitä haittaa tuommoisesta voisi olla.

Koodin määrä kasvaa, kokonaisuus alkaa repeilemään ja näiden seurauksena koodien ylläpito vaikeutuu. Tuollainen tiedosto-purkka menee ehkä omilla sivuilla, mutta kenellekkään vähänkään asiasta ymmärtävälle asiakkaalle en tuollaista edes kehtaisi ehdottaa, varsinkin kun flatfilen hallinta PHP:llä on aina vähän niin ja näin riippuen tapauskohtaisesti palvelimesta.

No, en voi väittää olevani 100% oikeassa, eikä tähän(kään) varmasti 100-prosenttisen oikeaa vastausta olekkaan. Mutta tämä on minun näkemykseni asiasta.

Mysql tietokantaa voi virittää toimimaan nopeammin. Epäilen että moni mysql-kanta pyörii ihan oletusasetuksilla --> muistia varattu oletukset.

leftover kirjoitti:

Lisäksi ei kannata yhtään väheksyä ohjeita, mutta ei kannata tehdä 102 sivuista manuaaliakaan palvelun käyttämiseksi.

Tämäkin on ehkä hieman näkökantakysymys mutta mielestäni web-palvelu ei ole hyvä, jos se tarvitsee erikseen ohjeen. Käytön tulidi olla helppoa ja itsestäänselvää. Lomakkeiden täyttöohjeet ovat tietenkin eri asia(esim juuri nuo vuosiluku jutut), tai muut käsiteltävälle sivulle mahtuvat ohjeistukset, kuten pakolliset kentät. Jos sivustolle joutuu erillisen ohjeen rakentamaan, on mielestäni menty vikaan.

leftover kirjoitti:

FAQ on hyvä luoda heti, mielellään puoliautomaattinen että voi jättää kysymyksiä jos sellaisia ilmenee.

Miten voi luoda usein esitetyt kysymykset sivun, jos yhtään kysymystä ei ole esitetty? Tuollainen FAQ:in käyttö on mielestäni täysin väärästä päästä lähtöisin. Tällöin FAQ:ista tulee helposti itsestäänselvyyksien kirjasto. Helposti käy niin että siellä on vastauksia kysymyksiin joita käyttäjille ei olisi tullut mieleenkään kysyä/huomauttaa/valittaa jos niistä ei olisi siellä erikseen mainittu. Vasta sillion, kun (hyviä) kysymyksiä oikesti tulee, tulisi FAQ muodostaa.

Tässäkin taas tietysti ilmaisen vain omaa mielipidettäni, en absoluuttista totuutta.

raezel kirjoitti:

Tämäkin on ehkä hieman näkökantakysymys mutta mielestäni web-palvelu ei ole hyvä, jos se tarvitsee erikseen ohjeen. Käytön tulidi olla helppoa ja itsestäänselvää. Lomakkeiden täyttöohjeet ovat tietenkin eri asia(esim juuri nuo vuosiluku jutut), tai muut käsiteltävälle sivulle mahtuvat ohjeistukset, kuten pakolliset kentät. Jos sivustolle joutuu erillisen ohjeen rakentamaan, on mielestäni menty vikaan.

Entäs sitten ohjeet BBCoden käyttämiseksi? Tai tarkennetun haun käyttämiseksi? Tai, tai, tai...

Kuten huomaat, web-sivuston ei tarvitse paljoakaan kasvaa peruskotskaportaalista kun ohjeita aletaan jo tarvitsemaan. Lisäksi on hyvä tehdä selväksi että shoutboxiin ei saa lisätä rasistisia kommentteja, x taulukkoa on syytä tulkita näin, y tiedot saadaan paikasta z ja niin edelleen. Mutta aivan kuten itse sanoit, on tämä näkökantakysymys.

raezel kirjoitti:

Miten voi luoda usein esitetyt kysymykset sivun, jos yhtään kysymystä ei ole esitetty? Tuollainen FAQ:in käyttö on mielestäni täysin väärästä päästä lähtöisin. Tällöin FAQ:ista tulee helposti itsestäänselvyyksien kirjasto. Helposti käy niin että siellä on vastauksia kysymyksiin joita käyttäjille ei olisi tullut mieleenkään kysyä/huomauttaa/valittaa jos niistä ei olisi siellä erikseen mainittu. Vasta sillion, kun (hyviä) kysymyksiä oikesti tulee, tulisi FAQ muodostaa.

Taas tulee vastaan damokleen miekka, teit niin tai näin on kädet aina verillä. Luonnollisesti, jos asiallisia, hyviä kysymyksiä ei ole esitetty, voi FAQissa olla johdanto siihen mitkä ovat hyviä kysymyksiä, ja lomake jolla saa lähettää kysymyksen ylläpitäjän sähköpostiin sekä mahdollisesti tietokantaan. Jos ylläpitäjä näkee tarpeelliseksi, voi hän asettaa kysymyksen näkyviin ja vastata siihen.

Tämä toteamukseni perustui siihen, että hyvin monissa tapauksissa palvelua betatestataan ennen virallista julkistamista. Betatestauksen aikana suurin osa kysymyksistä liittyy bugiin x, mutta monesti tulee myös hyviä kysymyksiä kuten "Mitä ideaa tässä palvelussa on?". Myös näitä beta-aikaisia kysymyksiä voi lisätä FAQiin, kuten myös voi lisätä kysymyksiä joita tekijällä itsellään on tullut mieleen palvelua tehdessä (ja jotka ovat vaatineet oikeaa pohdintaa).

raezel kirjoitti:

Tässäkin taas tietysti ilmaisen vain omaa mielipidettäni, en absoluuttista totuutta.

Osaako sitten kukaan sanoa absoluuttista totuutta, tuskin. Kaikki kehittyy ja se mikä oli vielä äsken absoluuttinen totuus voi olla huomenna jo puuta heinää. Nimenomaan tällaisilla virkistävillä "väittelyillä" saadaan parhaat tulokset aikaiseksi. Kaikki pitää kyseenalaistaa ilman kunnon perusteluja on oma mottoni :)

Tuosta tietokannan suunnitelusta - joka sinänsä on ihan oma tieteenalansa - sanoisin vielä muutaman kantapään kautta opitun vinkin.

Yksi oma tietokantasuunnitelun perusta on, että SQL-kyselyitä ei missään vaiheessa tarvitse ajaa loopissa. Data pitäisi saada kannasta ulos yhdellä selkeällä SQL-lauseella. Jostain muistan myös lukeneeni, että relaatio-tietokannoissa ei tulisi säilyttää samaa tietoa kahdessa paikassa. En tiedä kuinka absoluuttinen totuus tämä on, mutta itse ainakin lipsun tästä jonkin verran. Tässä vaiheessa tulee esiin tuo Antin mainitsema saman asian laskeminen toistuvasti. Ainakin MySQL:ään on hidasta ja raskasta tehdä kysely SELECT COUNT(foo) FROM bar WHERE IndeksiNro = 3, jos rivejä alkaa olemaan enemmän - vaikka IndeksiNro olisi kuinka indeksoitu sarake - joten useasti lasken tuon COUNT(*) vain kun rivien määrä todellisuudessa muuttuu ja säilyttelen tietoa sille sopivassa paikassa. Lisäksi jos kyse on vähänkään monimutkaisemmasta kannasta, testaan sen nopuden suuremmalla datamäärällä lähes poikkeuksetta.

Kokeilemalla ja tekemällä väärin oppii hyvin nopeastikkin tunnistamaan tietokannan pullonkaulat. Ei vaikea, pitkä SQL-lause välttämättä ole tietokannalle ollenkaan niin vaikea. Kokemuksesta tiedän, että Mysql pystyy helposti hakemaan dataa neljästä-viidestä taulusta pienen esseen pituisella lauseella muutamassakymmenessä millisekunnissa, vaikka tietokannan koko on 1Gt/1Mriviä. Hyvin suunnitellun tietokannan päälle on myös helppo rakentaa käyttöliittymä. Koodit pysyvät selkeinä ja johdonmukaisina, kun ei tarvitse paikkailla virheitä omilla virityksillä. Lisäksi koodin määrä tippuu murtoosaan verrattuna esimerkiksi toiseen ääripäähän: flatfileen, jossa kaiken joutuu tekemään itse.

Huh huh, tulipas sitä taas runoiltua työnantajan piikkiin...