Witam, mam serwis na serwerze nazwa.pl
Ostatnio odnotowałem więcej wizyt niż zwykle (3-5 tys. dziennie) i serwis został zablokowany z powodu przekroczenia czasu pracy procesora użytego przez skrypty php/cgi. Limit to 4h dziennie a przy 4,5 tys odwiedzin czas pracy serwisu wynosił 10h.

Próbowałem raz optymalizować kod bo dostrzegłem ogromną liczbę zapytań do bazy generowanych przez część podstron (w tym główną). Zrobiłem join zamiast pętli i liczba zapytań zmniejszyła się do max. 6. Niestety nie wpłynęło to na zmniejszenie czasu używanego przez skrypty php/cgi.

Timer symfony mówi, że czas generowania strony wynosi od 300 do 800 ms.
Czasami pierwsze wejście na stronę zajmuje dłużej, nawet 9000 ms.

Zastanawiam się nad dwoma rzeczami:

1. Czy jest to wina niezoptymalizowanego kodu serwisu (bo przy 5 tys. nie powinno być problemów) czy też jest to wina słabego hostingu (nie wiem czy limit, ktory nałożyli: 4h to dużo czy mało).

2. Jeżeli jest to wina raczej kodu serwisu to co może być przyczyną nieoptymalnego działania, albo co jakie parametry mogą mnie naprowadzić na trop.

Będę wdzięczny za radę, pozdrawiam.

Wydaje mi się (ale mogę się mylić, bo doświadczenia w takiej fuzji nie mam!), że połączenie: aplikacja w Symfony + hosting współdzielony + podwyższony ruch = klops. Jeżeli tak faktycznie jest to raczej nic z tym nie zrobisz. Możliwe również, że baza danych nie daje rady (o ile masz w niej naprawdę sporo danych oraz nie pozakładałeś indeksów), ale raczej obstawiałbym pierwszy wariant.

Raczej nie jest to wina symfony samego w sobie, a źle napisanego kodu/zaprojektowanej bazy danych.

Ciężko jest powiedzieć co może być przyczyną, ale proponowałbym upewnić się czy mechanizmy cache-a działają tak jak powinny, czy zapytania SQL generowane przez Doctrine/Propela/ręcznie są dobrze zoptymalizowane itp. itd.

Dzięki za odpowiedzi.

Jedyne co do tej pory udało mi się osiągnąć to zmniejszenie "Ilość danych przesłanych z/do baz danych". Z 10gb dziennie przy 3 tys. odwiedzin do 1,5 gb. Dziś rano włączyłem cache (tak, było wyłączone do tej pory ) ale w sumie żaden parametr się nie zmienił

Będę wdzięczny jeżeli ktoś zerknie na poniższe liczby i oceni choćby intuicyjnie w czym może się kryć tajemnica obciążenia generowanego przez ten serwis biorąc pod uwagę liczbę wizyt, charaketrystykę bazy i dane podawane przez hosting:

Symfony toolbar:
Czasy nie wychodzą raczej ponad 500 ms.
Zaobserwowałem, że włączenie serwisu pierwszy raz np. po godzinie często wymaga nawet ponad 10
sek. na wczytanie strony. Ale tylko raz - czy to może być jakiś trop? Na co może wskazywać?
Liczba zapytań do bazy nie przekracza 6 na żadnej podstronie.
Baza danych ma 3mb, główny obiekt to "ogłoszenie" i ma niecałe 400 rekordów - czyli w sumie nic nie ma...

Dane z serwera hostingowego dla wczoraj (około 2500 odwiedzin wg. google analytics):
0,29 mln żądań http (40% limitu dobowego)
6,5 h czasu zużytego przez procesor na skrypty cgi/php (to jest problem, limit dobowy = 4h)
1,5 h czasu wykonywania zapytań do bazy danych (25% limitu dobowego)
60 tys. połączeń do bazy danych (30% limitu)
0,16 mln zapytań do bazy danych (daaaleko od limitu, spadło po wdrożeniu Joina)
1,38 mln wierszy pobranych z bazy
1,75 gb danych przesłanych z/do bazy (15% limitu dobowego)


Po prostu nie pojmuję tej sytuacji, jeżeli serwis z 300 rekordami i 3 tys. odwiedzin generuje 10h czasu pracy serwera na skryptach to chyba coś jest bardzo nie tak? I to przy jednoczesnych rozsądnych czasach wczytywania strony. Co prawda to jest hosting współdzielony, ale 3 tys. to chyba ja robię jak testuję swoją stronę domową...

Zapewne jakieś "ważniejsze" elementy zapisane w cache uległy przedawnieniu i trzeba je zregenerować.

Czyli mamy rozumieć, że oscylują w granicach 400ms/stronę? To sporo...

Ja bym obstawiał na kilka rzeczy:
1) Źle skonfigurowany cache
2) Może masz front controllera ustawionego na środowisko deweloperskie, a nie produkcyjne
3) Jakieś niepotrzebne mapowanie rekordów z bazy danych na obiekty - to jest dosyć zasobożerny proces, zastanów się czy nie mógłbyś z niego w niektórych miejscach zrezygnować (jeżeli to byłoby problemem)
4) No chyba, że w kodzie masz gdzieś:

[PHP] pobierz, plaintext 
<?
 
for($i =0; $i < 10000; ++$i){
  preg_match('kill me', $abc);
}
[PHP] pobierz, plaintext 

No to wtedy nie ma się co dziwić.

Wielkie dzięki za pomoc, Crozin, myślę że rzeczywiście przyczyna może leżeć w złej konfiguracji cache. W tej chwili ustawiłem cache restrykcyjnie, sprwadzę czy w tym leży problem. Jeżeli tak to zajmę się subtelniejszą konfiguracją i dam znać czy pomogło. Jeszcze raz dzięki.

TAK, to było źle ustawione cache, czas z 7h spadł do 21 minut Nie wiem jak mogłem to przegapić. Dzięki!