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

Няма такъв филм. Няма как да няма такова време, защото това е едно от най-недостатъчните ресурси. @dpanajotov Прав сте потърсете проблем първо във вашата система. Предполагам и от хостинга ще ви помогнат със съвети.

Казвам, че не стават глупости заради процесорното време, тоест не следят под лупа като Суперхостинг, а не че можеш да си точиш процесора постоянно и никой нищо да не ти казва. А относно VPS Hybrid плановете, които препоръчах, там имаш дедикейтнати процесорни ядра, а не време. Дори и най-евтиният план ще се справи без проблеми със сайта на автора, стига да няма някакви бъгове, разбира се.
 
Забравих да кажа нещо. Имаме си една тестова версия, където пробваме различни неща, преди да ги пуснем в реалната версия. Уж е спряно за ботове и т.н.
Възможно ли е това да прави проблем? http://podmosta.bg/podmosta_test/
 
Забравих да кажа нещо. Имаме си една тестова версия, където пробваме различни неща, преди да ги пуснем в реалната версия. Уж е спряно за ботове и т.н.
Възможно ли е това да прави проблем? http://podmosta.bg/podmosta_test/
ЛЕЛЕЛЛЕЛЛЛЕ:
https://www.google.bg/search?q=site:podmosta.bg/podmosta_test/&oq=site:podmosta.bg/podmosta_test/&aqs=chrome..69i57j69i58.1972j0j4&sourceid=chrome&ie=UTF-8
 
Последно редактирано:
1. Аналитикса не е показателен, трябва да се гледат логовете за посщения в Awstats на cPanel - има го във всеки споделен хостинг. Обикновено там се виждат аномалии като паразитен трафик, който аналитикса не отчита.
2. Трябва да се провери сайта за фрагменти от код, които зареждат външни източници. Много често компрометирани сайтове имат подобен проблем, който дори и при една импресия, държи php процеса активен докато по някаква причина не бъде прекъснат "насилствено". Понякога това може да изяде адски много процесорно време.

Това се сещам на прима виста.
 
  • Like
Реакции: wsar
В такъв случай тези проблеми ще си останат и при другите хостинг компании. А знаете, че това оптимизиране влияе и на времето на зареждане и т.н

Влияе и на доста други неща... драсни ми на лични или у Фейса. Случайно се познаваме...

PS: Ако не си спомняш си бил на един WordCamp и оттам...
 
Колеги, успяхме да свалим процесорното време с около 100 минути. От около 360 сега падна на около 250. Много сериозно впечатление обаче ми направи следното:
посещенията нямат почти никакво значение! Например - вчера имахме два пъти по-малко посещения от онзи ден, но разликата в процесорното време е 5 минути за 24 часа. Явно сме нападнати от някакви ботове ли, не знам. В AwStats видях, че имаме доста посещения от ботове и половината Bandwidth се прави от Not viewed traffic *- не знам дали това има отношение.
 
Колеги, успяхме да свалим процесорното време с около 100 минути. От около 360 сега падна на около 250. Много сериозно впечатление обаче ми направи следното:
посещенията нямат почти никакво значение! Например - вчера имахме два пъти по-малко посещения от онзи ден, но разликата в процесорното време е 5 минути за 24 часа. Явно сме нападнати от някакви ботове ли, не знам. В AwStats видях, че имаме доста посещения от ботове и половината Bandwidth се прави от Not viewed traffic *- не знам дали това има отношение.
Има отношение. Сравнете трафика по дни но не по аналитикс, а по awstats.
 
  • Like
Реакции: wsar
А пробвахте ли варианта с WP Super Cache? Щото и аз преди имах същия проблем и от 110 минути процесорно време, го свалих на 10 минути - само с този кеширащ плугин. WP Total Cache само ми увеличаваше процесорното време...
 
Правилно Ви насочи @s1yf0x . По този начин ако имате бот, който прекалява със заявките можете да филтрирате.
 
1. В разддел day of month гледате колона Pages - това ще Ви даде по-адекватна представа за натовареността на php скриптовете, отколкото Google Analitycs
2. В раздел Hosts (Top 25) - виж 10-те IP адреса, които генерират най-много трафик. Ако е някакъв бот, който чопли постоянно там се вижда най-отчетливо
3. В раздел Pages-URL (Top 25) - виж първите 3 записа. Там можеш да се ориентираш кой е най-интензивно използвания ресурс от сайта. В повечето случаи е php скрипт.
4. В раздел HTTP Status codes - много хора го пропускат но ако топ 1 ти е Error 404 това може да е проблем. Проблем става при следните 2 ситуации:
- когато всичко, което не се намери, го пренасочваш към index.php - така дори и един статичен файл като картинка да не се открие се зарежда index.php
- когато някой болен SEO мозък, реши, че трябва да има custom php error page и направи скрипт 404.php който да обработва всички заявки, които са отправени до несъществуващ ресурс. Това е добре да се прави само и единствено на електронни магазини, но с особенно внимание.
 
  • Like
Реакции: wsar
Извинявам се, имах предвид WP Fastest Cache. Това е единственият кеширащ плугин за wordpress, който даде положителен резултат при мене (изключително добър резултат).
 
Извинявам се, имах предвид WP Fastest Cache. Това е единственият кеширащ плугин за wordpress, който даде положителен резултат при мене (изключително добър резултат).
Много грешен подход. Cache плъгините, се използват основно с цел повишаване на бързодействието на даден сайт, т.е. ако гониш performance. Консумацията на CPU се поправя с оптимизация на кода и начина, по който действа самото приложение. Кеширането като метод за намаляне на CPU консумацията е палеативна грижа - лекувате само симптомите, а не източника на проблема и при следващия пик в трафика ще имате по-голям проблем, който няма да може да се реши с плънг анд цък.
 
Здравейте на всички :)

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

Като цяло, откъм кеширане, мисля че сайта е доста оптимизиран с 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%;


Подрави!

 
Е в такива моменти мога само да се радвам, че си разцъквам NodeJS и всичко е асинхронно/
 
1 и 3 не ги мисли, това са статични ресурси. Поне ако
пуснаха Reverse Proxy услуга
това означава, че са сложили един nginx пред apache. Нямам идея за сетъпа (Никога не съм хоствал при суперите и никога няма да го направя)

Доколкото знам, това е скрипт, който се изпълнява докато някой админ е в админ-панела. Понеже ние имаме няколко администратора, които работят с админ панела по много пъти на ден изглежда, че този скрипт има много изпълнения.
Не е задължително. И от фронта може да се генерират заявки към него. Не лошо да се види action-a който му се пуска..

4. /wp-cron.php - Viewed 11,448 -
Тук изглежда има някакъв крон таск, който постоянно се изпълнява. Обаче, вече съм го прехвърлил да се изпълнява директно от linux системата (в CPanel) а не през php и Wordpress
в конфига
define('DISABLE_WP_CRON', 'true');
 
Дали може да обясниш защо това е толкова голям проблем? Ясно е за SEO-то и дублирането на съдържанието - беше огромна грешка създаването на такъв дублиран отворен сайт, но наистина в момента се учим - не претендираме да сме прота :) Как можем да оправим сега проблема най-ефикасно и с най-малко щети?
 

Горе