Оптимизация скоростта на WordPress блогове
Този път няма да говоря за SEO оптимизация, а за оптимизация на скоростта на WordPress блогове. Наложи ми се последните дни да намаля CPU минутите, които използват няколко мои добре развити блога с много посещения, включително и този. С времето те спечелиха много читатели, започнаха да използват и много разширения.
Всичко това нямаше как да не доведе до претоварване на сървъри. Засега се целя да се вмъквам в плановете на споделените хостинги, които ти дават да изразходваш от 20 до 40 CPU минути на ден в зависимост от хостинг компанията. Ще подредя съветите ми за оптимизация под формата на отделни точки:
1. Намалете броя на разширенията
Оказа се, че най-големият проблем правят разширенията. Много от тях са написани некадърно и просто са бавни. Целта е да се използват колкото се може по-малко разширения и такива, които са написани от хора, на които може да се има доверие. Дадох си сметка, че повечето от разширенията просто са излишни.
Примерно Мартин ме светна, че SEO паковете са ненужно нещо. Аз това отдавна го знаех, но ги използвах единствено за да си форматирам заглавията на отделните страници. Е, това можело да се прави и с функции в темата. Всичко друго от SEO пака за мен е глупост. Не обичам да си ограничавам ботовете :)
2. Използвайте FeedBurner
Чесно казано FeedBurner не ми е от любимите инструменти и много ме дразни, но реално погледнато спестява хитове от RSS четци директно по блога, които изразходват време и ресурси. Уж в WordPress хранилките са кеширани, но пак се генерират с PHP. А именно PHP изразходва времето на процесора.
3. Не разчитайте само на кеширане
Има много добри разширения за кеширане, като WP-Cache, WP-Super-Cache и други. Те са ефективни само при много посещавани блогове и блогове с малко на брой дневни коментари. При всякакви други случаи, тези разширения могат повече да натоварят сървъра, отколкото да са от полза.
4. Обърнете внимание на кеширането в браузъра
Някои няма да са съгласни с мен, но кеширането в браузъра чрез хедъри на HTTP си е важна част от оптимизацията според мен. Може да стане и с HTML мета таг. Най-добре е да няма никакви ограничения като Cache-Control: no-cache и браузърът сам да избира за колко време да пази кеш на всяка страница.
При тежки случаи, може да се зададе ръчно от един до няколко часа да се пази кеша Cache-Control: max-age=3600, must-revalidate. Понякога тези стойности зависят от настройките на сървъра и по подразбиране кеширането е забранено. Това от една страна забавя зареждането на сайта, от друга товари сървъра излишно.
За политиката на коментарите в блога
Доста хора взеха да ме питат защо трия коментарите им от блога или защо самия блог изобщо не ги публикува. Ако бяха чели повече от материалите, може би щяха да си отговорят, поне частично на въпроса.
1. Като за начало – трия безсмислените коментари и прекалено кратките такива. Коментари от рода „много яка статия“ не са полезни на никого. И аз не съм от тези, които вярват, че съдържанието е всичко и не ги оставям дори заради това.
2. Коментари, които целят просто да вземат връзка. Блогът дава реални връзки и много хора се възползват от това, но понякога прекаляват. Ако коментарът е смислен и полезен – ОК, иначе го приемам за СПАМ и се приключва с въпроса.
3. Обидни коментари, дори с градивна критика. Не твърдя, че съм много компетентен по някои въпроси, но поне се старая да съм полезен. Ако нещо не Ви харесва, можем да го обсъдим, но без да се обиждаме и да си налагаме мнението.
Причината за тази публикация е материалът ми за оптимизация на динамични сайтове. Там употребих терминът „кеширане“ с цел да опиша индексите в базите данни. Някои хора помислиха, че говоря за друго кеширане и започнаха да ме нападат.
Уча се от книгите на O’REILLY. Там се казва: „индексите в базите данни са предварително кеширане на информация с цел по-бързото й намиране в последствие“. Нека не издребняваме с глупости, а да си бъдем полезни.
Referring Links.com – Добавено кеширане
Referring Links скриптът взе доста да товари хостинга, затова се принудих да добавя кеширане на изходните резултати. Задачата изобщо не беше лесна, защото кеширането не е стандартно, а трябваше да се кешират JavaScript файлове. Просто ситуацията не е много обичайна.
Както и да е – справих се някак си, въпреки че съм нов в PHP и главата ми още е омотана с някои други видове езици и стандарти. Базата данни на скрипта надмина 140,000 записа в най-голямата си таблица. Там се съхраняват IP-адресите на всички реферали през последните 30 дни.
Според мен проблемът в натоварването е именно заявката, която извлича и групира резултатите. По репортите от host bulgaria не може много да се разбере къде точно е проблемът, защото срещу SQL ми пише натоварване 0.0, а при мен друго, освен сложната заявка, не товари.
Сега всеки сайт си има JavaScript файл с рефералните му сайтове и посещенията от тях. Този файл се обновява веднъж на ден и се вика само той. Базата данни също се чисти веднъж да ден от стари данни. Това са реферали преди 30 и повече дни. Така системата прави заявки само при отчитане на нов реферал.
Тези заявки само добавят информация и са бързи. При подобни кеширания, обаче, има един момент в сигурността, който много често се отминава. Кашираният файл обикновено се отваря с PHP функцията fopen(). Налага ни се програма от вида: $handle = fopen(„path/to{$_GET['filename']}.html“, „r“);
Ако променливата ‘filename’ е замърсена, един нарушител може да обходи файловата система с вкарване на низове от рода: „../../../../another/path/to/file%00„. Днес не се бях сетил за това, а е много опасно. В последствие подсигурих с регулярен израз валидността на входните данни при подобен вид отваряния на файлове.
Сега остава да се оглеждам за бъгове след последните промени. До сега скриптът не е спирал да работи, въпреки коренните си промени, вече на няколко пъти и натоварването. Дано и за в бъдеще не се случват проблеми, които да наложат спирането му. Днес ограничих заявките към базата с около 100,000 на ден :)
