затрийте го този тестов блог, няма какво да му се тества толкова на един wp блог със статииДали може да обясниш защо това е толкова голям проблем? Ясно е за SEO-то и дублирането на съдържанието - беше огромна грешка създаването на такъв дублиран отворен сайт, но наистина в момента се учим - не претендираме да сме протаКак можем да оправим сега проблема най-ефикасно и с най-малко щети?
Проблем с процесорното време
- Автор dpanajotov
- Начална дата
rscossworth
Active Member
Да седна да оптимизирам Wordpress ли? Що приказваш глупости? Колкото и да оптимизирам, като няма кеширане, постоянно ще рови из базата данни, а като се сервира кеширана страница не. Като имаш 10000 заявки дневно, само за една и съща страница, дали не помага кеширането?
s1yf0x
Well-Known Member
Защо да не го оптимизираш? Според теб е най-леката и оптимизирана cms ли? За-Що приказваш глупости?
VMiloykov
Well-Known Member
За да намалиш процесите от 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');
}
Щом си го направил с истински cron трябва да го спреш от wp-config.php. За целта трябва да добавиш в wp-config.php:
define('DISABLE_WP_CRON', true);
Sky
Well-Known Member
Това не е нужно, суперхостинг имат инструмент който прави всичко.
А гледайки нивото на програмиста е използвал именно него.
Костадин Петричков
New Member
Здравейте, отново,
Да, мога да потвърдя, че WP кроновете са изключени.
Скоро ще махна и тестовото копие на сайта и ще видим дали след това ще има промяна.
Относно ajax интерфейса на Wordpress, мисля да го изключа напълно, за да видим дали ще има драстична разлика в процесорното време - ако има, може след това да се настрои на някакъв по голям интервал (2-3 минути примерно).
Относно, модулите за кеширане Memcached и Redis - понеже имаме избор за ползване и на двете, но в момента е с Memchaced - мислите ли че ще има осезаем разлика ако се използва Redis? Доколкото знам, Redis превъзхожда Memcached.
Поздрави
Да, мога да потвърдя, че WP кроновете са изключени.
Скоро ще махна и тестовото копие на сайта и ще видим дали след това ще има промяна.
Относно ajax интерфейса на Wordpress, мисля да го изключа напълно, за да видим дали ще има драстична разлика в процесорното време - ако има, може след това да се настрои на някакъв по голям интервал (2-3 минути примерно).
Относно, модулите за кеширане Memcached и Redis - понеже имаме избор за ползване и на двете, но в момента е с Memchaced - мислите ли че ще има осезаем разлика ако се използва Redis? Доколкото знам, Redis превъзхожда Memcached.
Поздрави
karlson
Active Member
Опитайте да качите сайта тук, и проблема може да изчезне. https://www.cloudflare.com/
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, отколкото да оптимизираш Wordpress... Искам да видя, как ще оптимизираш една Wordpress инсталация, която при 50000 посещения дневно ще "харчи" не повече от 10 минути процесорно време (щото аз това съм го постигнал само с помощта на един плъгин). За сведение, "чистата" инсталация, без никакви плъгини, "харчеше" над 120 минути. Не знам какво ще му оптимизираш, ама тия 50000 пъти, по няколко заявки към базата данни, НЯМА КАК да изядат по-малко процесорно време от сервирането на един обикновен HTML (при спрени коментари, не се изпълняват почти никакви заявки към базата данни). Пък то, на приказки, можете да седнете и да си оптимизирате Windows-ите...
zlatko0o
Active Member
10 минути за 50k заявки - трудно, освен ако не е статичен сайт. Wordpress може да бъде оптимизиран стига да знаеш какво правиш!
s1yf0x
Well-Known Member
windows- -a се опитмизира много лесно. Маха се и се инсталира нормално функционираща операционна система
rscossworth
Active Member
Така се оптимизира и Wordpress
rscossworth
Active Member
Точно Wordpress, а не статичен сайт (той с кеширането си става статичен). Wordpress-а нямаше никакви други инсталирани плъгини освен WP Fastest Cache и при 50000 уникални дневно направи около 11 минути процесорно време... С други кеширащи плъгини, порцесорното време само се увеличаваше... Без никакви плъгини, процесорното време беше между 110 и 120 минути...