Голямо процесорно време - Как/Защо/Причини?

От: Голямо процесорно време - Как/Защо/Причини?

nginx безспорно е най-добрия вариант. С php-fpm или друг парсер вече е повод за дискусии :)
 
От: Голямо процесорно време - Как/Защо/Причини?

nginx безспорно е най-добрия вариант. С php-fpm или друг парсер вече е повод за дискусии :)

Ако направим сравнение между suphp, dso, cgi и старият fcgi, php-fpm (fastcgi) ще излезе в пъти по-икономичен от към процесорно време и удобен за оптимизация. Рамта не я броя, защото сегашните сървъри са с по 700гб+ , entry level, но и разликата от suphp е минимална. Дори няма нужда да намесваме nginx, cpanel с apache + php-fpm = pure win.

Добави това, че можеш да забравиш за suphp, suexec и т.н. С php-fpm всеки pool върви със собствени user, група, chroot, модули, php.ini, права, сокет/тцп и каквото се сетиш още, т.е. = сигурност.

Мен лично няма как да ме убеди някой, че което и да е друго решение към този момент може да изкара по-добри резултати, защото "си играя" с apache/php-fpm и nginx/php-fpm вече доста време. Това е при споделена среда. Ако става въпрос за сървър без панел nginx+php-fpm = 18000 заявки в секунда на vps с quad core и 1024 памет с wordpress сайт, това ми е рекорда за сега. (като това е нищо, хората от freenode стигат над 25 000 rps). Без Varnish, без добавки за кеширане, освен fastcgi cache от nginx, без никакви "екстри". Със стандартна конфигурация колко ще изкараш, 300? :p На повечето сървъри дали ще минеш и 50. Дори дискусиите са излишни :)

П.П. - ето ти малък пример:

Код:
Benchmarking predpriemach.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        LiteSpeed
Server Hostname:        predpriemach.com
Server Port:            80

Document Path:          /
Document Length:        414 bytes

Concurrency Level:      10
Time taken for tests:   28.204 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      631000 bytes
HTML transferred:       414000 bytes
[U][B][FONT=Arial Black]Requests per second:    35.46 [#/sec] (mean)[/FONT][/B][/U]
Time per request:       282.036 [ms] (mean)
Time per request:       28.204 [ms] (mean, across all concurrent requests)
Transfer rate:          21.85 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      122  139  20.1    131     259
Processing:   122  141  30.6    131     647
Waiting:      122  140  29.9    130     647
Total:        245  280  36.9    270     843

Percentage of the requests served within a certain time (ms)
  50%    270
  66%    282
  75%    291
  80%    299
  90%    322
  95%    347
  98%    380
  99%    394
 100%    843 (longest request)

Не случайно всички чакат да се появи модул за whm. Надявам се като съм готов с пачa за cpanel да го демонстрирам и нагледно с видео.
 
От: Голямо процесорно време - Как/Защо/Причини?

Здравейте,

Проверих, колегите са ви съдействали и процесорното време би трябвало да се върне в нормални граници. Вие сте споменал, че също сте направил някои оптимизации, които е много вероятно да дадат добър резултат.
В случая, доколкото проследих кореспонденцията, става дума за много агресивно индексиране от търсачките, съчетано с много посещения от някои ботове. За съжаление, подобни казуси се случват от време на време. Уведомили сме ви за високото потребление на CPU ресурс, основно за да имате в предвид какво се случва със вашият хостинг акаунт и със сайтовете, които са разположени на него. Ние предоставяме и доста подробна статистика, за да прецените и кога и къде е необходимо да се оптимизира, да се ограничат ботове (както в случая) или да се премине към по-подходящо хостинг решение. Подробните статистики са помогнали на много собственици и разработчици на сайтове, да ги оптимизират и да вземат правилни решения за развитието на техните (или на техни клиенти) проекти.

Трябва да отбележа също, че акаунта ви отдавна използва fastcgi и поради това трудно може да се говори за голям overhead от самото PHP. Както вече споменах, причината тук е била друга.
Вие отдавна сте наш клиент и знаете, че винаги се стараем да съдействаме максимално адекватно на всички поставени от вас запитвания. Интересно в случая е, че процесорното време за един ден наистина е било много голямо над 11 пъти (1100%) от обявеното на нашият сайт за този хостинг план. Въпреки това, работа на сайт (както и на всички останали сайтове за акаунта) е била нормална.


Здравейте,

От няколко дена нещо ми напада сайта и прави огромно процесорно време от рода на 400 до 1500мин.. което е много, за слаб сайт. ( 500 уникални на ден )

Лафя с хостинга (суперхостинг ) те спряха уж "лошите ботовете" но нещо пак го има тоя проблем, единия ден сайта е към 100 и под сто, което е нормално в другия ден се дигат в няколко пъти.
Хостинга нещо не ми реагират адекватно, искат да ме набутат да плащам за отделна машинка.

Вие каква ще споделите от опита си?
 
От: Голямо процесорно време - Как/Защо/Причини?

Я вижте какво се случва при мен - http://prntscr.com/1w0vfh
Ето и роботите: http://prntscr.com/1w0vvt
При влизане в cpanel-а нали в ляво има графики за моментнотно натоварване на процесор и използваната памет - там сега като влязох например гледам процесора е на 50%?! От какъв зор не знам.
Ето и статистика от Използвани ресурси: http://prntscr.com/1w0xnp
Доста често като съм в админ панела на сайта пък ми дава тайм аут и се влачи доста. Има нещо доста гнило...

Не знам вече какво да направя...
 
Последно редактирано:
От: От: Голямо процесорно време - Как/Защо/Причини?

Пратете ми кой е акаунта на лично съобщение да проверя.

Я вижте какво се случва при мен - http://prntscr.com/1w0vfh
Ето и роботите: http://prntscr.com/1w0vvt
При влизане в cpanel-а нали в ляво има графики за моментнотно натоварване на процесор и използваната памет - там сега като влязох например гледам процесора е на 50%?! От какъв зор не знам.
Ето и статистика от Използвани ресурси: http://prntscr.com/1w0xnp
Доста често като съм в админ панела на сайта пък ми дава тайм аут и се влачи доста. Има нещо доста гнило...

Не знам вече какво да направя...
 
От: От: Голямо процесорно време - Как/Защо/Причини?

Здравейте rusanov,

Благодаря за отговора.

Приятно съм изненадан, че сте се информирали доста добре за проблема.
Определено сте отделили време за да проучите за какво става на въпрос и лично за мен като Ваш клиент.
Като цяло съм доволен от услугите и поддръжката, винаги съм получавал бързи отговори и решения - благодаря за което.
Имам доста клиенти на които лично съм препоръчвал Вашият хостинг и до ден днешен те са си при Вас.
Оценявам, че е нямало спиране на сайта макар голямото надвишаване!

Аз все още гледам да оптимизирам от тук от там сайта за да влиза в нормите.
Вчера с радост мога да споделя, че изразходеното време е било в рамките на допустимите количества. Надявам се така да продължавам.

Следя нещата и ще реагирам максимално бързо, целта е ясна - Сайта да работи нормално и да не пречи на Вас и другите Ваши клиенти.








Здравейте,

Проверих, колегите са ви съдействали и процесорното време би трябвало да се върне в нормални граници. Вие сте споменал, че също сте направил някои оптимизации, които е много вероятно да дадат добър резултат.
В случая, доколкото проследих кореспонденцията, става дума за много агресивно индексиране от търсачките, съчетано с много посещения от някои ботове. За съжаление, подобни казуси се случват от време на време. Уведомили сме ви за високото потребление на CPU ресурс, основно за да имате в предвид какво се случва със вашият хостинг акаунт и със сайтовете, които са разположени на него. Ние предоставяме и доста подробна статистика, за да прецените и кога и къде е необходимо да се оптимизира, да се ограничат ботове (както в случая) или да се премине към по-подходящо хостинг решение. Подробните статистики са помогнали на много собственици и разработчици на сайтове, да ги оптимизират и да вземат правилни решения за развитието на техните (или на техни клиенти) проекти.

Трябва да отбележа също, че акаунта ви отдавна използва fastcgi и поради това трудно може да се говори за голям overhead от самото PHP. Както вече споменах, причината тук е била друга.
Вие отдавна сте наш клиент и знаете, че винаги се стараем да съдействаме максимално адекватно на всички поставени от вас запитвания. Интересно в случая е, че процесорното време за един ден наистина е било много голямо над 11 пъти (1100%) от обявеното на нашият сайт за този хостинг план. Въпреки това, работа на сайт (както и на всички останали сайтове за акаунта) е била нормална.
 
От: Голямо процесорно време - Как/Защо/Причини?

имах същия проблем с процесорното време преди време - оптимизирах сайта отностно този проблем (speed page) и постигнах положителни резултати - 97%, но не и в процесорното време, което продължаваше да е "up" допустимото според хостинг плана. Не знам какъв хостинг план ползваш - аз ползвах shared, но като преместих сайта на читав хостинг, където няма ограничения за процесорното време всичко се оправи.
 

Горе