Arkisto heinäkuu 3, 2009

WordPress ja ongelma kuvien lisäämisessä

WordPress.com tarjoaa 3 GB tilaa kuville ja muulle medialle. Kuvien tallentaminen palvelimelle tapahtuu Add an Image -napin kautta, josta kuvat tallentuvat Galleriaan (kyseiseen blogitekstiin lähetetyt kuvat) tai Media Libraryyn (kaikki kuvat). Ennemmin tai myöhemmin käy kuitenkin niin, että kuvien lähettäminen WordPress.comiin onnistuu, mutta niiden liittäminen artikkeleihin ei ole mahdollista. Insert into post -nappi puuttuu juuri lähetetyn kuvan alta, mitä kummaa?

Mänty, Pinus sylvestris

Mänty, Pinus sylvestris

PNG-tiedostojen ja isojen JPGiden kanssa hetken odottelu auttaa. WordPress.comissa pyörii skripti, joka varmistaa palvelimelle lähetetyt kuvat kuvatiedostoiksi. Pienet JPG:t saavat vahvistuksen yleensä saman tien, mutta PNG-tiedostojen kanssa joutuu joskus odottelemaan. Insert into post -nappi tulee näkyviin vasta, kun tiedosto on saanut palvelimen hyväksynnän.

Tammi, Quercus robur

Tammi, Quercus robur

Galleria-sivulla voi blogiin liittää usean kuvan sarjan. Tälle sivulle ei milloinkaan ilmesty Insert into post -nappia, sen sijaan kun Galleria-dialogissa on useampi kuin yksi kuva, ilmestyy sivun alalaitaan Insert gallery -nappi.

Kanadantuija, Thuja

Kanadantuija, Thuja occidentalis

Yksittäisten kuvien lisääminen tapahtuu siis näin: klikkaa harmaata Add an image -nappia, joka on Upload/Insert tekstin oikealla puolella, muokattavan tekstikentän yläpuolella. Lähetä kuva palvelimelle ja lisää kuvan tiedot, jos kuva on tässä vaiheessa jo saanut varmistuksen, lähetyssivun alalaidassa on Insert into post -nappi. Muussa tapauksessa tallenna kuvan tiedot ja avaa samasta dialogista Media Library. Odottele hetkonen ja tarkastele lähetetyn kuvan tietoja klikkaamalla show. Kun kuva on varmistettu, tällä sivulla näkyy nappi Insert into post.

Kommentoi

Drupal nopeammaksi, osa 2/X

Tavoitteena on muuttaa erittäin hitaasti toimivat, kehitysvaiheessa olevat verkkosivut julkaisukuntoon. Alustana sivuilla on Drupal 6, tietokantahaut on toteutettu Viewsillä ja aseteltu nodeihin block-osioihin kirjoitetuilla views_embed_view()-funktioilla. Muita moduleita ovat CCK, Date, ImageField, I18N, ICME ja TinyMCE.

Aloitustilanteessa verkkosivut ovat periaatteessa valmiit ja niillä on jonkin verran sisältöä, joka on pääasiassa tekstiä ja muutamia pieniä kuvia. Sivut on siirretty palvelimelle, jossa ne on tarkoitus siirtää tuotantoon. Sivunlataus kestää keskimäärin uskomattomat 15 sekuntia. Palvelimella muistia riittää ja rasitusaste on lähellä nollaa.

Ensimmäinen ja helpoin tapa nopeuttaa toimintaa on kääntää Drupalin oma välimuisti päälle. Asennuksen yhteydessä tulin kuitenkin ensin tarkistaneeksi MySQL:n konfiguraation, josta puuttui tietokannan välimuisti kokonaan. Asetustiedosto on nimeltään my.cnf ja se löytyy tavallisesti /etc -hakemistosta.

cat /etc/my.cnf

Konfiguraatio näkyy ruudulla. Jos parametrit query_cache_type, query_cache_size tai query_cache_limit puuttuvat, ne kannattaa pikapikaa lisätä. Query_cache_type määrittää, onko tietokannan välimuisti päällä. Arvo 1 on päällä, arvo 0 pois päältä ja arvo 2 on päällä vain silloin kuin suoritukseen tuleva SQL-lauseke ehdottaa välimuistin käyttöä. Perus-Drupalin kanssa arvo 1 on sopiva ja voisi myös sanoa että välttämätön. Query_cache_size on välimuistille varattava koko. Suuruus riippuu sivustoista mutta olen käyttänyt arvoa 40 (MB) ja hyvin on tultu toimeen. Query_cache_limit on arvo megabitteinä, minkä suuruiset haut korkeintaan tallentuvat välimuistiin. Oletusarvona on 1 MB, joka lienee käytössä kirjoittamattakin. Drupalin kanssa 1 MB sopii meille. Lisää/korjaa rivit my.cnf:iin käyttämällä vimiä tai muuta tekstieditoria.

query_cache_type=1
query_cache_limit=1
query_cache_size=40

MySQL:n pitää vielä lukea asetukset uudelleen, jotta muutos astuu voimaan:

/etc/init.d/mysql reload (tai restart jos reload ei toimi)

Testisivumme puolittivat juuri sivunlataukseen kuluvan ajan. 7,5 sekuntia on edelleen kelvoton tulos, joten lisätoimia tarvitaan. Palataan takaisin yleensä ensimmäiseksi suoritettavaan vaiheeseen, eli Drupalin oma välimuisti päälle. Asetus löytyy kohdasta admin/settings/performance tai Administration -> Site configuration -> Performance. Caching modeksi kannattaa yleensä laittaa normal ja kaikki pakkausvaihtoehdot päälle, eli Page compression enabled, Block cache enabled, Optimize CSS files enabled ja Optimize JavaScript files enabled. Huomaa, että tämän jälkeen lähdekoodiin tai blockkeihin tehdyt muutokset eivät välttämättä tule näkyviin ennenkuin tältä samaiselta Performance-sivulta on käyty klikkaamassa Clear cached data -nappia.

Tehdään asetusten tallennus ja uloskirjautuminen, Drupalin pääkäyttäjälle (nid 1) ei koskaan tarjoilla välimuistissa olevia sivuja joten sivujen kokeilu pitää suorittaa anonyyminä käyttäjänä tai muuna sisään kirjautuneena käyttäjänä. Pienen klikkailun jälkeen voidaan todeta, että sivut ovat nopeutuneet, mutta sivunlatausaika vaihtelee edelleen 2,5 sekunnista reilusti yli viiteen sekuntiin.

Boosterit käyttöön

Viisi sekuntia jokaisen sivun aukeamiseen ei todellakaan ole tyydyttävä tulos. Tietokantayhteys on nyt kunnossa ja Drupal käyttää oikopolkuja sivun muodostamiseen. Mitä voimme vielä tehdä?

Flowchart

Flowchart

Ylläoleva kuva on napattu ilman lupaa Drupal.orgista ja muiden tietojen puutteessa sen tekijä lienee Jonah Ellison (linkki lähteeseen).

Kuva havainnollistaa loistavasti, miten Authcache-moduli nopeuttaa sivunlatausta. Sivuista tallennetaan HTML-versiot, jotka ovat valmiina lukua varten. Tällaisen toiminnon tuottavia moduleita on useita. Authcache on siitä erilainen, että tässä on mahdollista suorittaa tietokantahakuja sivunlatauksen jälkeen JavaScriptin avulla. Näin HTML-kopioita voidaan käyttää myös sisäänkirjautuneiden käyttäjien palvelemiseen.

Authcache on kuitenkin melko monimutkainen ottaa käyttöön, joten tässä käytämme yksinkertaista Boost-moduulia. Boost tekee sivujen juurihakemistoon cache-kansion, johon tallentuu HTML-versiot kaikista sisäänkirjautumattomien käyttäjien, tässä tapauksessa kaikkien sivujen käyttäjien ylläpitäjää lukuun ottamatta, avaamista sivuista.

Boostin asennuksessa on muokattava sivujen juurihakemistossa olevaa .htaccess-tiedostoa. Asennus sujuu näin:

  1. Lataa ja pura Boost-moduuli modules-kansioon ja ota se käyttöön Drupalin moduulisivulta
  2. Luo juurihakemistoon kansio cache ja tämän sisään kansio omadomain.fi
  3. Anna cache/ ja cache/omadomain.fi/ -kansioihin sopivat käyttöoikeudet Drupalia pyörittävälle käyttäjänimelle (esimerkiksi chown -R omadomain:omadomain cache ja chmod -R u+rwx cache)
  4. Mene Boostin asetuksiin, jotka löytyvät Performance-sivulta
  5. Kopioi .htaccess-asetukset leikepöydälle
  6. Muokkaa .htaccess-tiedostoa (joka löytyy kohdasta omadomain.fi/.htaccess) ja liitä Boostin asetukset oikeaan kohtaan.
  7. Käynnistä Boost sen Drupalin asetussivulta
  8. Kirjaudu ulos ja kokeile sivujen toimintaa

Ensimmäinen sivunlatauskerta anonyyminä käyttäjänä ei eroa tavallisesta sivunlatauksesta. Seuraavissa nopeusero tulee näkyviin: sivunlataus kestää keskimäärin 1,4 sekuntia! Tällä vauhdilla sivut voi hyvillä mielin julkaista.

Boostin asennukseen liittyen cronjobin toimivuus pitää vielä tarkistaa. Cron virkistää HTML-versiot sivuista normaalin cron-ajon tahtiin. Boost neuvoo asettamaan /sites/default/settings.php -tiedoston base_url-muuttujalle arvon, jos ongelmia esiintyy.

Kommentoi

Drupal nopeammaksi, osa 1/X

Drupalilla tehdyt verkkosivut takkuilevat? Yksinkertaisimmatkin sivut latautuvat todella hitaasti? Sivun välimuisti on päällä ja vauhti paranee, mutta nopeutta pitäisi silti saada lisää?

Drupal on erittäin monikäyttöinen alusta kaikenlaisiin verkkosivuihin. Monipuolisuudesta seuraa tekninen monimutkaisuus ja Drupalilla toteutetut verkkosivut saattavat käyttää vain murto-osaa kaikista ohjelmiston tarjoamista ominaisuuksista. Normaalin sivunlatauksen yhteydessä palvelimella tapahtuu vaikka mitä, joista moni toiminto voisi jäädä tavanomaisen sivunlatauksen kohdalla käyttämättäkin.
Normaalisti palvelimen muisti riittää pyörittämään Drupalia riittävän nopeasti, jotta sivunmuodostuksen vaatima aika pysyy pienenä. Pullonkaulana sivun muodostusajassa on tietokantahaut. Drupal voi käyttää normaalin noden muodostamiseen 20 tietokantahakua, jos tietokantayhteydet eivät ole kunnossa, sivujen muodostaminen voi kestää ikuisuuksia.

Työkaluja nopeuden seuraamiseksi

Nopeuden viilaaminen on parasta aloittaa kellottamalla sivunlatausten kestoja. Vaikka pääasiallisena huolenaiheena on tarkastella sekunnin ja pidempien aikojen hidastumisia, jotka voi havaita silmämääräisestikin, nopeuden mittaaminen siihen tarkoitetuilla ohjelmilla on varmempaa. Joskus hitaushan voi johtua käytetystä työasemasta, jonka takkuilulla ei ole mitään tekemistä sivunlatauden vaatiman ajan kanssa.

Drupalin Devel-moduuli on Drupalin sisäisten toimintojen mittaamiseen käytettävä ohjelma. Develillä saa monenlaista muutakin infortaatiota sivujen muodostumisesta, mutta yksinkertaisimmillaan sillä saa näkyviin sivun rakentamiseen kuluneen ajan. Tämä aika on nimenomaan se aika, joka alkaa Drupal saadessa sivupyynnön ja loppuu Drupalin ilmoittaessa sivunluonnin olevan valmis. Välissä on tavallisesti toistakymmentä tietokantahakua. HTTP-kutsuja ei käsittääkseni tähän aikaan tule.

YSlow on Yahoon kehittämä ilmainen lisäosa niinikään ilmaiseen Firebug-sovellukseen. Devel on hyödyllinen tutkittaessa Drupalin sisäistä toimintaa, mutta varsinaiset tiedot sivunlataukseen kuluneista vaiheista voidaan selvittää vain selaimesta kellottamalla. YSlow on tehty juuri tähän ja lisäksi se osaa neuvoa, millaisia hidastavia tekijöitä kuhunkin sivuun liittyy. YSlow tarvitsee Firebug-ohjelman, joka puolestaan toimii vain Firefoxissa. Ilmaisia kaikki ja saatavissa miltei kaikille alustoille.

Asennuksen jälkeen YSlow ilmestyy Firefoxin oikeaan alalaitaan, josta klikkaamalla ohjelma avaa ikkunan osittain sivun päälle. Ikkunasta voi käynnistää selaimessa parhaillaan auki olevan sivun tarkastamisen. Tarkastuksen jälkeen YSlow antaa sivulle nopeuteen ja tekniseen esteettömyyteen perustuvan arvosanan (numero), arvosanan teknisen toteutuksen laadusta (kirjain) ja listaa puutteet sivunlataukseen vaikuttavista tekijöistä ja neuvoja niiden korjaamiseksi. Valtaosa sivuista saa YSlowilta arvosanan 70…79. Google.fi saa 99, nethack.org 97. 71 tai alle on niin hidas sivu, että surffaaja ehtii jo ärsyyntymään. Hitauden sietäminen on tietenkin suhteellista, mutta tavoitteena pitäisi kaikkien sivujen kohdalla päästä vähintään arvoon 75-80. Kunnollisella palvelimella olevan, pelkkää validia HTML:ää sisältävän sivun tulisi päästä 90 yläpuolelle ilman optimointia.

Toivon, että pystyn kirjoittamaan Drupalin nopeuttamisesta monta artikkelia. Käytössä on tällä hetkellä Drupal 6.12 ja ensi vuonna tilanne tullee muuttumaan Drupal 7:n myötä. Sivunlatauksien nopeuttamiseksi tulee jatkuvasti uusia tekniikoita, kuten äskettäin ymmärtämäni, jännittävän niminen CSS Sprite -menetelmä. Lisää aiheista seuraavassa artikkelissa. Tähän vielä pari hyödyllistä linkkiä:

http://wimleers.com/article/improving-drupals-page-loading-performance

http://2bits.com/articles/tips-on-speeding-up-your-drupal-sites.html

Kommentoi