Ja ei ole need trikid tegelikult nii veidrad midagi – kui korra ära õpid ei saa enam ilma hakkama. Alustama peame aga natuke kaugemalt, sest mistahes probleemi lahendamine algab selle olemuse mõistmisest ja veebiserveri puhul ei saa me läbib logide ja serveri koormuse uurimiseta. Ning selleks on abiks võtta kasutusele SSH … ehk käsurida.
Sissejuhatus – kasuta SSHd
Käsurealt saad reaal-ajas vaadata aktiivseid protsesse, andmebaasi- ja veebi-päringuid, samuti otsida huvipakkuvaid mustreid kuitahes suurtest logifailidest, mille FTPga alla-lohistamine võtaks aega ja mis tavapärased tekstiredaktorid kokku jooksutaks.
Millest pihta hakata? Kui kasutad Mac OSi või Linuxit on mugavaim õpetus GitHubi Generating a new SSH key and adding it to the ssh-agent, mina googeldan abi vajades alati “github ssh key“… aga kui soovid Windowsi, PuTTY ja Zone-spetsiifilisemat abi, siis leiad ka meie abitekstidest juhise SSH ühenduse loomine.
Ma olen täiesti kindel, et kui õpid alljärgnevate supervõimete nimel SSHd kasutama… siis järgmine kord kohtudes teed mulle (oma eelistusest lähtuvalt) välja koogi või õlle 🙂
Trikk #0 – vaata logisid!
Nii, mis meil siin serveris siis toimub?
cd domeenid/www.example.com/logs/ tail -f apache.ssl.access.log | grep-php
Käsk tail
kuvab faili lõppu ja -f
värskendab väljundit jooksvalt, | grep-php
otsib tulemusest päringuid, mis käivitasid PHP ehk veebirakenduse:
Nagu näha käib pidev lammutamine wp-login.php
kallal, lisaks hakkavad silma wp-cron.php
ehk ajastatud tegevused ja hulk erinevaid (otsi)roboteid: Yandex, Bing, DuckDuckGo, Ahrefs, Semrush… Õnneks on minu veebis rea lõpus olev ajakulu suurusjärgus 0.02-0.15 sekundit ehk olematu, aga kui aeg hakkab olema üle sekundi… siis võivad botid kergesti kurja teha.
grep-php, grep-phpslow ja grep-phpveryslow on Zone serverites seadistatud aliased, mis aitavad leida PHP- või aeglase PHP-päringuid. Kui tahad neid seadistada oma arvutis või mujal, siis käsk
alias
näitab retsepti 🙂
Trikk #1 – asenda wp-cron.php süsteemse cronjob’iga
Aga proovime ühte teist saiti ja grep-phpslow
annab sellise tulemuse:
Ouch! 10-50 sekundit töötav cron-päring hõivab ühe veebi teenindamiseks mõeldud PHP-protsessidest… mõistlikum oleks seadistada süsteemne CRONTAB.
Sellest räägib eraldi help.zone.eu artikkel WordPressi cron-tööde seadistamine.
Trikk #2 – piira robots.txt abil botte
Kuigi robots.txt
on rangelt soovituslik tuleb nentida, et suur hulk logides silma hakkavaid botte käituvad igati viisakalt ehk loevad vähemalt kord nädalas robots.txt
faili ja arvestavad selle suunistega.
Minul on tavaks soovitada kõigil robotitel mitte pärida sagedamini kui 10 sekundi takka ning keelata päringud, milles sisaldub ?
ehk millele on lisatud mingid parameetrid, olgu selleks siis s=otsisõna
või color=pink&size=42
kujul e-poe filtrid.
User-Agent: * Crawl-delay: 10 Disallow: /*?* User-agent: AhrefsBot User-agent: AhrefsSiteAudit User-agent: SEMrushBot User-agent: SemrushBot User-agent: SemrushBot-SA User-agent: MJ12bot Disallow: /
Täiendavalt võib keelata meie jaoks väärtust mitte omavad botid, nt kui me ei kasuta Ahrefs ja Semrush SEO-tööriistu on kogu nende tekitatav koormus vesi vaid konkurentide veskile… ja miks neid nuumata?
robots.txt
puhul tuleks meeles pidada, et tühi reavahetus ei ole ilu pärast vaid eristab erinevatele bottidele suunatud plokke ja User-Agent: *
reegel kehtib vaid neile, kes endale sobilikku plokki ei leia.
Trikk #3 – kiireks ja jõuliseks piiramiseks kasuta .htaccess’i
Vahel ei pruugi aga robots.txt
piisav olla, sest seda kontrollitakse periooditi samas kui sinu koormuse-probleem on valus just täna. Kuna viisakad botid panevad oma nime User-Agent
’isse kirja, siis saab veebiserverile anda korralduse neile sobilikku veateadet näidata.
Selleks tuleb veebi juurkataloogis olevasse .htaccess
faili lisada nimekiri soovimatutest User-Agent
’itest ning lubada neile ligipääs ainult robots.txt
’ile – lootuses, et nad tulevikus sellega arvestama hakkavad:
RewriteEngine On RewriteCond %{REQUEST_URI} !/robots.txt$ RewriteCond %{HTTP_USER_AGENT} Semrush [NC,OR] RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR] RewriteCond %{HTTP_USER_AGENT} AhrefsSiteAudit [NC,OR] RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC] RewriteRule .* - [R=503,L]
Trikk #3b – piira hiinabottide ligipääs
Kohati kohtab aga eriti agressiivseid botte, mis tulevad hulgalt erinevatelt IPdelt, ei huvitu robots.txt
’ist ega evi äratuntavat UserAgent
’it.
Aga sageli tulevad nad Hiina IP-aadressidelt. Zones on veebiserver seadistatud nii, et igal päringul on automaatslet küljes IP-aadressile vastav maakood, miska on lihtne lisada .htaccess faili järgmine plokk:
SetEnvIf MM_COUNTRY_CODE ^(CN) countryBlock Deny from env=countryBlock
Ehk kui maakood algab CN
’iga, siis Deny
.
NB! Selliste maa-põhiste piirangute kasutamine võiks piirduda lühiajalise kaitsega – vastasel puhul võib mh Google Ads keelduda reklaame avaldamast. (tx, Helen & relumee.ee)
Vähendab kindlasti olulisel määral müüki Hiinasse, aga küllap tulevad hiinlaste hordid Helsinki lennujaama ja Talsinki tunneli kaudu peagi ise kohale, seega no harm done.
Trikk #3c – brauseri-cache ilma pluginata
Kui see .htacces juba editoris lahti on… teeks veel ühe pisiparanduse. Nimelt saab väga lihtsalt brauseritele öelda, et ei ole vaja igal lehekuvamisel käia küsimas kas mõni pilt või CSS on muutunud:
<IfModule mod_mime.c> # Add mime types that might be missing from server conf AddType font/woff2 .woff2 </IfModule> <IfModule mod_expires.c> # Enable expirations ExpiresActive On # Default directive ExpiresDefault "access plus 1 day" # HTML ExpiresByType text/html "access plus 0 seconds" # Data ExpiresByType text/xml "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType application/json "access plus 0 seconds" # Favicon ExpiresByType image/x-icon "access plus 1 year" # Images ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/webp "access plus 1 month" # CSS ExpiresByType text/css "access plus 1 hour" # Fonts ExpiresByType font/woff "access plus 1 year" ExpiresByType font/woff2 "access plus 1 year" # Javascript ExpiresByType application/javascript "access plus 1 year" </IfModule>
Trikk #4 – vaata, mis wp_options tabelis toimub
WordPressi puhul võiks edasi liikuda mitmes suuna – pagebuilder? WPML? turvaplugin? megamenüü? … aga jätame need hilisemaks. Kogenud koristaja võtab esimes asjana ette wp_options
tabeli, sest:
- sinna salvestatakse vaikimisi kogu “ajutine” kraam nn transient’idena;
- transientide suurus võib olla kuni 100 megabaiti – ja seda siis üks kirje!
- neid kirjeid või olla kümneid tuhandeid;
- ja isegi kui progejad on arvestanud aegumise järel kustutamisega… võib see käia
wp-cron
’ile üle jõu; - seal on veerg
autoload
mis ei ole indekseeritud, ehk igal lehekuvamisel peab SQL otsima kümnete tuhandete ridade hulgast neid, mille indekseerimata väärtus onyes
; - kirjeid võidakse uuendada igal päringul või ajastatud toimingul, mille tulemusena kasvab andmebaas kontrollimatult (à la 1 ööga 100 gigabaiti).
Ehk kui wp_options
on suurem kui ca 1500 kirjet ja kirje sisu üle … ütleme, et üle max mõnesaja kilobaidi, siis on tegemist olulise probleemiga.
Trikk #5 – vaata, mida kood teeb
… see blogipostitus on olnud mustandi olekus täpselt 3 kuud – sest ma ei jõudnud 5nda triki kirjutamiseni esimese hooga. Aga ma arvan, et ma tahtsin kirjutada oma varasema Miks mu veeb aeglane on? Vaata BlackFire abil järgi! artikli lihtsamaks.
Kahjuks… seda lihtsamaks kirjutada väga ei anna. Sest kõige olulisem oleks pikk nimekiri “kuidas tõlgendada/lahendada olukoda X?” … ja meie mõlema jaoks oleks mõistlikum aja/rahakasutus kui ma konkreetse juhtumi (raha eest) ette võtaks ja arendajale juhised annaks.