Спиране ‘версии на публикацията’ в WordPress
Трудно ми беше да измисля заглавие на тази публикация. Сигурно сте забелязали, че от версия 2.6 WordPress пази по няколко версии на всяка публикация, като броят им зависи от това колко време сме я писали и колко пъти сме я променяли. Лично за мен това е напълно излишна опция, която прави базата данни в пъти по-голяма и цялата система в пъти по-бавна.
Отдавна се каня да намеря решение на този проблем, трябваше да ми остане малко свободно време и днес това се случи. Стимулът беше, че от Гугъл официално признаха, че скоростта на сайт ще е от значение за позиционирането му. Спирането на тази опция, наречена „revisions“, ускорява значително скоростта на WordPress.
В момента пиша този пост много по-лесно от преди, защото той много по-бързо се запазва автоматично. Спирането на тази ненужна и бавеща екстра се състои от три етапа. Първо задаваме директива на WordPress, да спре да пази нови версии на публикациите. След това изчистваме базата данни от всички непубликувани версии и накрая оптимизираме таблиците.
1. Спиране запазването на нови версии
За целта трябва да се добави следната директива към системата:
define('WP_POST_REVISIONS', false);
По принцип би-трябвало да става с добавяне на това във функциите на темата или направо във файла wp-config.php, но при мен така не стана. Затова го направих като разширение, което може да си изтеглите от тук и да инсталирате ръчно, чрез качване от компютър. Ако всичко е наред, ще спрете да виждате версиите на публикациите.
2. Изчистване на базата данни
За целта изпълнете следната заявка в базата данни на блога:
DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';
Излишно е да казвам преди да пуснете това да си направите архив на базата данни! Заявката е бавна, в един от блоговете ми три към 23 секунди и отнесе няколко десетки хиляди излишни записа. Всичко зависи от големината на блога, важното е да имате търпение и да не прекъсвате заявката.
Редакция: Заявката има един мааалък страничен ефект – някои връзки от blogroll спират да се показват. За целта е необходимо да се редактират и save-нат наново. Не поемам никаква отговорност, ако заявката вреди и на нещо друго.
3. Оптимизиране на таблиците
Тук е лесно, просто изпълнете и тази заявка в базата данни:
OPTIMIZE TABLE wp_posts, wp_term_relationships, wp_postmeta;
Всичко това го направих на всичките си блогове, отне ми доста време, но смятам, че си заслужава. Все-още вървят – шегувам се :) Ако не ви се рискува, то изпълнете само точка едно. Ако сте се захванали с точка две, то точка три е безобидна и може само да ви е от полза. Приятно триене за един по-бърз WordPress :)
П.С.: Поиграх си да направя удобни бутони за споделяне в популярните социални мрежи в края на всяка публикация. Надявам се, че ще са полезни.
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 на ден :)
Оптимизация на динамични сайтове и скриптове
Не, този път няма да пиша за SEO оптимизация, както обикновено, а за един друг вид оптимизация, която пренебрегваме още по-често – оптимизацията на кода на даден сайт или скрипт. Тя е също толкова важен елемент от успеха на един сайт, колкото е и SEO оптимизацията.
Повечето хора си качват сайтовете на така популярния и удобен „споделен хостинг“. Но този хостинг е споделен и трябва да се спазва определена култура, когато се използва. Различните сайтове използват споделени ресурси и когато един сайт товари повече и заема повече памет, то това се отразява на всички други.
Рядко се налага един сайт да има толкова много потребители и изчислителни нужди, че да се наложи да работи на VPS или на собствен сървър. Последните ми разработки около referring sites скрипта ми доказаха, че един сайт с много изчисления и потребители може да се оптимизира и да хаби ресурси колкото обикновен блог.
Хората рядко мислят за оптимизация на програмите си. В днешния свят на постоянно развиващи се технологии, сякаш може с малко по-скъп хардуер да се подкара всяка една програма. В същност не е така – когато даден сайт започне да прави значителен брой посещения – тогава проблемът с ресурсите може да се реши само чрез оптимизация на скриптовете му.
Ето и някои основни принципи, без да се задълбавам:
1. Използване на функции, изискващи по-малко ресурси.
Примерно в PHP е много по-ефективно да се използват функциите strpos() и strstr() за търсене на низ в текст, отколкото функцията preg_match(). Последната е проектирана за регулярни изрази и заема много повече памет и ресурси. Проверявайте за всяка функция какво прави и дали няма по-добра алтернатива.
2. Минимизиране на връзките към базата данни.
Това може би е най-често срещания проблем при разработка на уеб скриптове – големият брой връзки към базата данни. Често начинаещите програмисти извикват връзка всеки път, когато им е нужна дадена информация. В повечето случаи има начин необходимата информация да се вземе предварително и наведнъж, и да не се занимава допълнително SQL сървърът.
3. Използване на индекси (кеширане) на SQL ниво.
Повечето системи за обработка на бази данни, като MySQL, поддържат така нареченото кеширане на колони. То е полезно, когато ще търсим в дадена колона или ще сортираме по нея. Примерно, ако имате колона client и често Ви се налага заявка от вида: „SELECT * FROM clients WHERE client LIKE ‘%Ivanov’“, то добавете индекс към client.
4. Кеширане на информация с цел избягване на повторни заявки
Става въпрос за класическото кеширане, при което примерно създаваме отделен HTML за всяка страница и го качваме на сървъра. При следващо извикване на съответната страница, не товарим базата данни със заявки, а просто зареждаме кешираното копие. При промени в скрипта, всичко се кешира на ново, което е много по-оптимизиран процес.
5. Използване на бази данни в трета нормална форма
Това е малко по-сложно за кратко обяснение, но идеята е да има повече малки таблици с външни ключове между тях. Целта е да се избягват служебно празни полета и/или повтаряне на данни в дадена колона. Така се пести място и многократно се ускорява работата на системата. В MySQL външни ключове се правят при основа InnoDB.
6. Използване на PHP или сървърния скрипт само където е необходимо
Може цяла една HTML или друга страница да се генерира чрез PHP, примерно, но това изисква много повече функции и ресурси. Изглежда и по-сложно. Затова сървърният скрипт трябва да се използва само там, където наистина има нужда от него. Примерно, за изписване на текст не е нужно да викате echo „Ала бала“;, а е достатъчно да си напишете текста.
7. Избягване на типове като BLOB в SQL системата
Много често с цел улесняване на дадена задача, ни е по-лесно да качим дадена снимка или видео директно в базата данни в бинарна форма. Това обаче е страшно натоварващо за системата. Много по-ефективно е да качим снимките/видеотата в директория и в базата данни да пазим само връзки към тях. А BLOB се използва само когато няма друг начин.
Това са основните моменти, за които се сетих. Разбира се, няма как да съм изчерпателен. Оптимизацията си е цяло едно изкуство, но винаги може да се оптимизира повече. Въпросът е къде е разумната и приемлива граница. Чрез избягването на най-често срещаните грешки се вдига ефективността многократно. Тук описах повечето от тях.
