D
Deleted member 1942
Guest
-
Последно редактирано от модератор:
Проблем с процесорното време
- Автор dpanajotov
- Начална дата
hristonev
Well-Known Member
И аз това се опитах да кажа
dpanajotov
New Member
Забравих да кажа нещо. Имаме си една тестова версия, където пробваме различни неща, преди да ги пуснем в реалната версия. Уж е спряно за ботове и т.н.
Възможно ли е това да прави проблем? http://podmosta.bg/podmosta_test/
Възможно ли е това да прави проблем? http://podmosta.bg/podmosta_test/
Sky
Well-Known Member
odmosta.bg/podmosta_test/&oq=site
s1yf0x
Well-Known Member
1. Аналитикса не е показателен, трябва да се гледат логовете за посщения в Awstats на cPanel - има го във всеки споделен хостинг. Обикновено там се виждат аномалии като паразитен трафик, който аналитикса не отчита.
2. Трябва да се провери сайта за фрагменти от код, които зареждат външни източници. Много често компрометирани сайтове имат подобен проблем, който дори и при една импресия, държи php процеса активен докато по някаква причина не бъде прекъснат "насилствено". Понякога това може да изяде адски много процесорно време.
Това се сещам на прима виста.
2. Трябва да се провери сайта за фрагменти от код, които зареждат външни източници. Много често компрометирани сайтове имат подобен проблем, който дори и при една импресия, държи php процеса активен докато по някаква причина не бъде прекъснат "насилствено". Понякога това може да изяде адски много процесорно време.
Това се сещам на прима виста.
mobilio
Well-Known Member
Влияе и на доста други неща... драсни ми на лични или у Фейса. Случайно се познаваме...
PS: Ако не си спомняш си бил на един WordCamp и оттам...
dpanajotov
New Member
Колеги, успяхме да свалим процесорното време с около 100 минути. От около 360 сега падна на около 250. Много сериозно впечатление обаче ми направи следното:
посещенията нямат почти никакво значение! Например - вчера имахме два пъти по-малко посещения от онзи ден, но разликата в процесорното време е 5 минути за 24 часа. Явно сме нападнати от някакви ботове ли, не знам. В AwStats видях, че имаме доста посещения от ботове и половината Bandwidth се прави от Not viewed traffic *- не знам дали това има отношение.
посещенията нямат почти никакво значение! Например - вчера имахме два пъти по-малко посещения от онзи ден, но разликата в процесорното време е 5 минути за 24 часа. Явно сме нападнати от някакви ботове ли, не знам. В AwStats видях, че имаме доста посещения от ботове и половината Bandwidth се прави от Not viewed traffic *- не знам дали това има отношение.
s1yf0x
Well-Known Member
Има отношение. Сравнете трафика по дни но не по аналитикс, а по awstats.
rscossworth
Active Member
А пробвахте ли варианта с WP Super Cache? Щото и аз преди имах същия проблем и от 110 минути процесорно време, го свалих на 10 минути - само с този кеширащ плугин. WP Total Cache само ми увеличаваше процесорното време...
dpanajotov
New Member
За какво точно да гледам в AwStats?
Утре ще пробваме със Super Cache.
Утре ще пробваме със Super Cache.
s1yf0x
Well-Known Member
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 който да обработва всички заявки, които са отправени до несъществуващ ресурс. Това е добре да се прави само и единствено на електронни магазини, но с особенно внимание.
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 който да обработва всички заявки, които са отправени до несъществуващ ресурс. Това е добре да се прави само и единствено на електронни магазини, но с особенно внимание.
rscossworth
Active Member
Извинявам се, имах предвид WP Fastest Cache. Това е единственият кеширащ плугин за wordpress, който даде положителен резултат при мене (изключително добър резултат).
s1yf0x
Well-Known Member
Много грешен подход. Cache плъгините, се използват основно с цел повишаване на бързодействието на даден сайт, т.е. ако гониш performance. Консумацията на CPU се поправя с оптимизация на кода и начина, по който действа самото приложение. Кеширането като метод за намаляне на CPU консумацията е палеативна грижа - лекувате само симптомите, а не източника на проблема и при следващия пик в трафика ще имате по-голям проблем, който няма да може да се реши с плънг анд цък.
Костадин Петричков
New 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%;
Подрави!
Аз съм програмистът на въпросния сайт. Реших, че е крайно време да се включа в темата, като дам малко повече технически детайли на всички хора, които се опитват да ни помогнат.
Като цяло, откъм кеширане, мисля че сайта е доста оптимизиран с 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%;
Подрави!
Torbalan Trolski
Well-Known Member
1 и 3 не ги мисли, това са статични ресурси. Поне ако
define('DISABLE_WP_CRON', 'true');
това означава, че са сложили един nginx пред apache. Нямам идея за сетъпа (Никога не съм хоствал при суперите и никога няма да го направя)
Не е задължително. И от фронта може да се генерират заявки към него. Не лошо да се види action-a който му се пуска..
в конфига
define('DISABLE_WP_CRON', 'true');
Sky
Well-Known Member
Това е по-голям проблем в момента.
dpanajotov
New Member
Дали може да обясниш защо това е толкова голям проблем? Ясно е за SEO-то и дублирането на съдържанието - беше огромна грешка създаването на такъв дублиран отворен сайт, но наистина в момента се учим - не претендираме да сме прота Как можем да оправим сега проблема най-ефикасно и с най-малко щети?
Как можем да оправим сега проблема най-ефикасно и с най-малко щети?