Проблем с процесорното време

ReminD

Well-Known Member
Дали може да обясниш защо това е толкова голям проблем? Ясно е за SEO-то и дублирането на съдържанието - беше огромна грешка създаването на такъв дублиран отворен сайт, но наистина в момента се учим - не претендираме да сме прота :) Как можем да оправим сега проблема най-ефикасно и с най-малко щети?
затрийте го този тестов блог, няма какво да му се тества толкова на един wp блог със статии
 
  • Like
Реакции: Sky

rscossworth

Active Member
Много грешен подход. Cache плъгините, се използват основно с цел повишаване на бързодействието на даден сайт, т.е. ако гониш performance. Консумацията на CPU се поправя с оптимизация на кода и начина, по който действа самото приложение. Кеширането като метод за намаляне на CPU консумацията е палеативна грижа - лекувате само симптомите, а не източника на проблема и при следващия пик в трафика ще имате по-голям проблем, който няма да може да се реши с плънг анд цък.
Да седна да оптимизирам Wordpress ли? Що приказваш глупости? Колкото и да оптимизирам, като няма кеширане, постоянно ще рови из базата данни, а като се сервира кеширана страница не. Като имаш 10000 заявки дневно, само за една и съща страница, дали не помага кеширането?
 

s1yf0x

Well-Known Member
Да седна да оптимизирам Wordpress ли? Що приказваш глупости? Колкото и да оптимизирам, като няма кеширане, постоянно ще рови из базата данни, а като се сервира кеширана страница не. Като имаш 10000 заявки дневно, само за една и съща страница, дали не помага кеширането?
Защо да не го оптимизираш? Според теб е най-леката и оптимизирана cms ли? За-Що приказваш глупости?
 

VMiloykov

Well-Known Member
2. /wp-admin/admin-ajax.php - Viewed 19,872 -
Доколкото знам, това е скрипт, който се изпълнява докато някой админ е в админ-панела. Понеже ние имаме няколко администратора, които работят с админ панела по много пъти на ден изглежда, че този скрипт има много изпълнения.
Чудя се дали да го огранича? Това би орязало някои функционалности, но пък... Простете за глупавия въпрос, но може ли да е атака?
За да намалиш процесите от admin-ajax.php(WP Heartbeat) може да използваш плъгина Heartbeat Control. Примерно може да го сложиш през 35 или 60 секунди.
https://wordpress.org/plugins/heartbeat-control/

Ако пък не ти трябва може да го изключиш напълно като добавиш това в functions.php на темата:
add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}


4. /wp-cron.php - Viewed 11,448 -
Щом си го направил с истински cron трябва да го спреш от wp-config.php. За целта трябва да добавиш в wp-config.php:
define('DISABLE_WP_CRON', true);
 

Sky

Well-Known Member
Щом си го направил с истински cron трябва да го спреш от wp-config.php. За целта трябва да добавиш в wp-config.php:
define('DISABLE_WP_CRON', true);
Това не е нужно, суперхостинг имат инструмент който прави всичко.
А гледайки нивото на програмиста е използвал именно него.
 
Здравейте, отново,

Да, мога да потвърдя, че WP кроновете са изключени.

Скоро ще махна и тестовото копие на сайта и ще видим дали след това ще има промяна.

Относно ajax интерфейса на Wordpress, мисля да го изключа напълно, за да видим дали ще има драстична разлика в процесорното време - ако има, може след това да се настрои на някакъв по голям интервал (2-3 минути примерно).

Относно, модулите за кеширане Memcached и Redis - понеже имаме избор за ползване и на двете, но в момента е с Memchaced - мислите ли че ще има осезаем разлика ако се използва Redis? Доколкото знам, Redis превъзхожда Memcached.

Поздрави
 

s1yf0x

Well-Known Member
Здравейте на всички :)

Аз съм програмистът на въпросния сайт. Реших, че е крайно време да се включа в темата, като дам малко повече технически детайли на всички хора, които се опитват да ни помогнат.

Като цяло, откъм кеширане, мисля че сайта е доста оптимизиран с W3 Total Cache, и би трябвало тук да няма проблеми. Освен това, както каза dpanajotov, Суперхостинг ни пуснаха Reverse Proxy услуга, която прави сайта доста бърз при зареждането.

Сега, нека да дам отговор на s1yf0x - ето и статиските на AwStats:
1. В разддел day of month гледате колона Pages
1. wp-content/plugins/yet-another-related-posts-plugin/includes/styles_thumbnails.css.php/B] - Viewed 25,670 -
Това е скрипт за стилизиране на плъгина за намиране на подобни статии. След изключването му не видяхме чак толкова сериозен спад в процесорното време - може би с около 10% спад. Но 10% са си 10% и се събират, така че ще търсим по-лека алтернатива.
2. /wp-admin/admin-ajax.php - Viewed 19,872 -
Доколкото знам, това е скрипт, който се изпълнява докато някой админ е в админ-панела. Понеже ние имаме няколко администратора, които работят с админ панела по много пъти на ден изглежда, че този скрипт има много изпълнения.
Чудя се дали да го огранича? Това би орязало някои функционалности, но пък... Простете за глупавия въпрос, но може ли да е атака?
3.wp-content/plugins/menu-icons/includes/library/icon-picker/css/types/fontawesome-webfont.woff2 - Viewed 17,043 -
Това са иконки, които се ползват насам-натам в сайта...
4. /wp-cron.php - Viewed 11,448 -
Тук изглежда има някакъв крон таск, който постоянно се изпълнява. Обаче, вече съм го прехвърлил да се изпълнява директно от linux системата (в CPanel) а не през php и Wordpress

2. Hosts статистиката:
1. 195.191.148.85 - Pages 15,151 - Hits - 15,455 -
whois показва, че сървъра е на Суперхостинг (както Sky по-горе спомена);
2. 185.45.67.194 - Pages 4,183 - Hits 4,199 - whois показва, че сървъра е на Суперхостинг (както Sky по-горе спомена);
3. 95.87.240.43 - Pages 3,798 - Hits 13,652 - whois показва,че сървъра е на NET1;
4. 89.25.47.250 - Pages 3,220 - Hits 4,776 - whois показва, че сървъра е на БТК;

3. HTTP Status codes
1. 404 - Hits 13,315 - Percent 38,7%;
2. 403 - Hits 9,270 - Percent 26,9%;
3. 301 - Hits 4,320 - Percent 12,5%;


Подрави!
1- плъгина е CPU time excessive и в който и форум да погледнеш за WP си има доволно количесто мнения за същия проблем. Въпреки, че php скрипта, който си цитирал не е най-натоварващата част от него има и други негови скриптове, които тормозят най-вече mysql
2- тук може и да е от работата на администраторите (не е добра идея да ги ограничаваш, губи се смисъла на сайта), но може и да е от някой widget който се зарежда на home page-а и който рови вътре. Можеш да погледнеш за такъв като отвориш сайта в incognito режим, без да си се логнал в wp-admin частта и прегледаш source-а на заредената страница, за препратки към admin-ajax.php. Обикновено са някакви JS-и
3 не ти е проблем, а 4 си го фикснал съдейки по другите мнения.

Нормално е първият IP да е на Superhosting, все пак имаш някакво r-proxy отпред, въпреки че не съм сигурен какво е - nginx, squid, varnish, haproxy или нещо друго. Но и 2-та вече идва малко в повече. Погледни дали някой друг техен клиент не ти скрейпва съдържанието. Все пак са най-големия хостинг доставчик, напълно възможно е, друг сайт на техен сървър да си е харесал твоите писания. Свалете си raw-logs от cPanel и анализирайте какви ресурси се теглят от тези IP-та, само GET заявки ли са или има и други.

Обърни внимание на 404-ките. Пак в raw-logs виж кои са най-много - към определена страница или статични файлове като картинки, css-и или JS-и. Най-вече обърни внимание на това какво се случва ако се отвори несъществуваща картинка - опитай в браузър. Нормалното поведение на WP- е да те пренасочи към index.php. Обясних по-горе за проблема с 404 ако има много redirects.
 

rscossworth

Active Member
Защо да не го оптимизираш? Според теб е най-леката и оптимизирана cms ли? За-Що приказваш глупости?
Щото е по-лесно да напишеш нов CMS, отколкото да оптимизираш Wordpress... Искам да видя, как ще оптимизираш една Wordpress инсталация, която при 50000 посещения дневно ще "харчи" не повече от 10 минути процесорно време (щото аз това съм го постигнал само с помощта на един плъгин). За сведение, "чистата" инсталация, без никакви плъгини, "харчеше" над 120 минути. Не знам какво ще му оптимизираш, ама тия 50000 пъти, по няколко заявки към базата данни, НЯМА КАК да изядат по-малко процесорно време от сервирането на един обикновен HTML (при спрени коментари, не се изпълняват почти никакви заявки към базата данни). Пък то, на приказки, можете да седнете и да си оптимизирате Windows-ите...
 

zlatko0o

Active Member
Щото е по-лесно да напишеш нов CMS, отколкото да оптимизираш Wordpress... Искам да видя, как ще оптимизираш една Wordpress инсталация, която при 50000 посещения дневно ще "харчи" не повече от 10 минути процесорно време (щото аз това съм го постигнал само с помощта на един плъгин). За сведение, "чистата" инсталация, без никакви плъгини, "харчеше" над 120 минути. Не знам какво ще му оптимизираш, ама тия 50000 пъти, по няколко заявки към базата данни, НЯМА КАК да изядат по-малко процесорно време от сервирането на един обикновен HTML (при спрени коментари, не се изпълняват почти никакви заявки към базата данни). Пък то, на приказки, можете да седнете и да си оптимизирате Windows-ите...
10 минути за 50k заявки - трудно, освен ако не е статичен сайт. Wordpress може да бъде оптимизиран стига да знаеш какво правиш!
 

s1yf0x

Well-Known Member
Щото е по-лесно да напишеш нов CMS, отколкото да оптимизираш Wordpress... Искам да видя, как ще оптимизираш една Wordpress инсталация, която при 50000 посещения дневно ще "харчи" не повече от 10 минути процесорно време (щото аз това съм го постигнал само с помощта на един плъгин). За сведение, "чистата" инсталация, без никакви плъгини, "харчеше" над 120 минути. Не знам какво ще му оптимизираш, ама тия 50000 пъти, по няколко заявки към базата данни, НЯМА КАК да изядат по-малко процесорно време от сервирането на един обикновен HTML (при спрени коментари, не се изпълняват почти никакви заявки към базата данни). Пък то, на приказки, можете да седнете и да си оптимизирате Windows-ите...
windows- -a се опитмизира много лесно. Маха се и се инсталира нормално функционираща операционна система :)
 
  • Like
Реакции: wsar

rscossworth

Active Member
10 минути за 50k заявки - трудно, освен ако не е статичен сайт. Wordpress може да бъде оптимизиран стига да знаеш какво правиш!
Точно Wordpress, а не статичен сайт (той с кеширането си става статичен). Wordpress-а нямаше никакви други инсталирани плъгини освен WP Fastest Cache и при 50000 уникални дневно направи около 11 минути процесорно време... С други кеширащи плъгини, порцесорното време само се увеличаваше... Без никакви плъгини, процесорното време беше между 110 и 120 минути...
 

Горе