[How To] Проблема с процесорното време - има решение.

ktomov

Premium
В предната ми публикация бях написал как да се отървете от досадният ромб, сега идва време на нещо по-сериозно - натоварването върху самата машина.
За голяма част от вас не знам как стоят нещата, но бях на VPS с доста добри параметри и хАпачето определено изнемогваше. Ползвах какви ли не плъгини за кеширане на информацията. Стигнах до един извод - Wp-SuperCache или както там се води е пълен боклук.
Моите съвети от тук нататък са:
1) Ползвайте W3 Total Cache
2) Ако сте на споделен хостинг оставете всичко както си е, единственото което трябва да промените е опцията за компресиране на файлове, т.е. сложете го на "none". Автора на плъгина казва, че е "non recommended", но аз мисля да го уборя - в повечето хостинг фирми ви предлагат трафик, който така или иначе трудно ще използвате, но пък имате проблеми с процесорното време.
Е представете си ситуация в която вие имате да речем над 2000 страници, които са достъпни от потребителите. Според вас колко процесорно време използва самият gzip за да компресира това нещо и да го изпрати на потребителя? Ако се случи 100 потребителя да посетят една статия - добре, ами ако имате голям трафик към отделни такива? Извода е такъв, че gzip и mod_deflate ви товарят в пъти повече хАпачето от колкото самият wordpress.
3) Ако не сте на споделен хостинг - инсталирайте си APC и го ползвайте заедно с горният плъгин, като тук вече може да си позволите да ползвате компресия, защото така или иначе, едва ли ще успеете да натоварите толкова много машинката, а страниците ви ще се отварят за секунди.

Overal: Благодарение на горният плъгин и APC успях да смъкна load average на машина която обслужва над 200 000 импресии дневно от 2.5 на 0.7
Не знам на колко от вас тези цифри ви говорят нещо, но определено всичко е в пъти по-добре от преди.
И този пост ми е последен за днес, утре още :)
 
От: [How To] Проблема с процесорното време - има решение.

Ползвах дълго време WP Super Cache и мисля,че наистина е пълен боклук тази добавка.Махнах я и ми се струва,че сега блога ми работи по-добре и зарежда по-бързо.
 
Последно редактирано:
От: [How To] Проблема с процесорното време - има решение.

Да вдигна и аз една тема от гробищата. Някои ще кажи ли W3 Total Cache или друг кеширащ плъгин да ползвам. Сайт главно с щатски трафик, 1500-2000 уникални дневно, 120 статии плюс снимка къв всяка. Споделен хостинг. Прегледах 3-4 статии по блоговете за W3 Total Cache , но бяха с различни настройки.

А защо святам, че е бавен? Ами тествах го на WebPagetest

От там стигнах до извода, че трябва да го забързам малко. :)
 
От: [How To] Проблема с процесорното време - има решение.

В комбинация с кеширащ плъгин на страниците, използвай и кеширащ на mysql заявките. DB Cache Reloaded ползвам аз.
 
Re: От: [How To] Проблема с процесорното време - има решение.

В комбинация с кеширащ плъгин на страниците, използвай и кеширащ на mysql заявките. DB Cache Reloaded ползвам аз.
Keширайки страницата, ти изобщо не правиш заявка към БД за да извличаш данните за генерирането на страницата.
Струва ми се безсмислено да използваш и двете. Като да използваш 2 кеширащи плугина едновременно.
 
Re: От: [How To] Проблема с процесорното време - има решение.

Keширайки страницата, ти изобщо не правиш заявка към БД за да извличаш данните за генерирането на страницата.
Струва ми се безсмислено да използваш и двете. Като да използваш 2 кеширащи плугина едновременно.

Напълно съм съгласен с това мнение. Целта на всички кеширащи добавки в wordpress е да правят статични html файлове, които не разходват допълнителни връзки към базата данни или карат php да компилира целия код за пореден път, за това и подобни добавки са ненужни.
Друг е въпроса, че някои плъгини пък възпрепятстват правилната работа на w3 total cache и wp super cache.
 
Re: От: [How To] Проблема с процесорното време - има решение.

Напълно съм съгласен с това мнение. Целта на всички кеширащи добавки в wordpress е да правят статични html файлове, които не разходват допълнителни връзки към базата данни или карат php да компилира......
и какво има WP което иска да се компилира ?
 
Може да съм използвал неправилна думичка в случая и по-правилно щеше да ползвам думичка като "изпълни", но въпреки това не смятам, че изказването ми е неправилно.
Дефиницията за компилирам и сам може да си я намериш. Това, че е масово използвана за прехвърляне на даден код в бинарен вид, далеч не значи че думата се ползва само за това. Изпълняването на самите функции от php низове от функции в статичен html който се вижда чрез нашите браузери може да се нарече "компилиране" на код, нали?
 
От: [How To] Проблема с процесорното време - има решение.

1) Ползвайте W3 Total Cache
2) Ако сте на споделен хостинг оставете всичко както си е, единственото което трябва да промените е опцията за компресиране на файлове, т.е. сложете го на "none".

откъде да му дам да не компресира файловете?
 
Това го писах за по-стара версия на добавката.
Опцията в новите се намира в Browser Cache Settings и се маха тикчето на Enable HTTP (gzip) compression
 
.... , нали?

не.

Може да си страшно гуру за wp, ама мен лично не ме кефи как описа нещата(не казвам че са грешни).
nvm в wordpress секцията по принцип нямам работа.
 
От: [How To] Проблема с процесорното време - има решение.

Има и един друг момент. Може не плугина за кеш да е счупен, а настройките му.
Може би не кешира страниците, които най-често се използват, а тези които се зареждат най-рядко.
При сайт с много вътрешни страници (хиляди), съществува друг проблем. Предвид, че посетителите ви четат произволни страници, а не се концентрират върху начална страница или даден категория примерно, то това значи, че голям процент от страниците ще бъдат достъпени само 1-2 пъти за целия ден, от хора попаднали директно на тях при търсене в Google или препратка от друг сайт. T.e. колко повече вътрешни страници, толкова по-малка вероярност двама души да отворят една и съща страница. Само ограничен брой страници (като началната например), ще бъдат достъпвани десетки пъти дневно.
До тук ясно? А сега си представете, че кеширащия ви плугин е настроен да кешира страниците за период от 2 часа. Много вероятно е никой да не отвори повторно страницата в рамките на 2 часа, при което кеша си изтича без да се използва изобщо. И ползата от него е никаква. Решението е да се вдигни живота на кеша за едни страници и намали за други. Това не знам дали е възможно с плугините на WP, но теоретично (а и доказано практически) действа.
Освен това, има теми на WP, които за да изведат листинг на постовете, придружени от малка картинка (thumbnail), я генерират всеки път отново и отново с помощта на PHP скрипт, работещ на принципа на кепча (създава картинка и я изпраща на браузъра, без да я съхранява като файл). Освен това файла на картинката не се извиква като локален файл (т.е. нещо от сорта на /home/site/public_html/images/kartinka1.jpg, a като отдалечен файл http://site.com/images/kartinka1.jpg). Това допълнително забавя работата на скрипта и при по-малко от 1000 импресии дневно вече се усеща огромен пик на процесорното време. Такава тема за WP е WP Max

В случай, че използвате къстъм система, ето и няколко съвета за оптимизация на използването процесорно време: http://paste2.org/p/1524353
 
От: Re: От: [How To] Проблема с процесорното време - има решение.

Keширайки страницата, ти изобщо не правиш заявка към БД за да извличаш данните за генерирането на страницата.
Струва ми се безсмислено да използваш и двете. Като да използваш 2 кеширащи плугина едновременно.
Може и така да е. И аз не бях сигурен в това, но от hostgator веднъж ми бяха казали да сложа super cache и db cache, ако нямаше смисъл щяха да кажат само едното.
 
От: [How To] Проблема с процесорното време - има решение.

Някаква идея защо не ми позволява да го стартирам

Сигурни ли сте, че искате да направите това?

Моля, опитайте отново.
 

Горе