[CMS], [PHP] Naprawa niedziałającego CMS-a, Kto winien za błąd 503 Opcje

[DGP]

Dzialajacy acz z trudem CMS zaczal nagle wyrzucac blad 503 tak od strony www jak i panela administracyjnego. Firma wykonawcza z Warszawy wina obarcza providera (NR 1. na naszym rynku (IMG:style_emoticons/default/smile.gif) ) a ten z powrotem aplikacje. Kto jest winien i jak to sprawdzic?

Przegaldajac kod PHP strony widac np wiele niedorobek - bo czy pozostawione w liniach kodu informacje: TO DO: Do przemyslenia..., 90% kodu wylatuje, Tak musi dzialac bo dziala... nie swiadcza o braku profesjonalizmu...?

Dodac nalezy ze strona ma wlasny CMS, oparta jest na Front Controlerze i Smaty

Pomozcie znalezc wlasciwe rozwiazanie

Pozdrawiam

Daniel

[thek]

A ja bym raczej podejrzewał nieoptymalny kod. Jeśli provider jest, jak piszą, nr1 na rynku to zapewne się broni przez fatalnie napisanym kodem poprzez przydzielanie limitu zasobów. Strona ma kod w rozsypce i zanim się zdąży przetworzyć serwer ja killuje, by nie wpłynęła swoim kiepskim działaniem na serwisy innych użytkowników. Sam coś o tym wiem, bo gdy przyszedłem do firmy gdzie pracuję przez jakiś czas zastanawialiśmy się co jest grane, gdyż z rana zawsze sypało sie 503. Po uzyskaniu slow-logów od dostawcy zidentyfikowaliśmy winowajcę w postaci jakiegoś starego skryptu bannerów, który dosłownie zajeżdżał cały serwer. Tworzył o określonych godzinach masę tablic tymczasowych i rekordów do nich by się aktualizować. W efekcie baza szybko spuchła do ponad 1GB(!) i każdego ranka dochodziły kolejne rekordy. Serwer przez to był w zasadzie nie do odwiedzenia przez jakieś 15-20 minut a kolejne 10 dochodził do stanu normalnego. Jeśli już wcześniej chodził źle to znaczy tylko, że jeszcze bardziej ktoś w nim nagrzebał i bardziej spaprał to, co już działało źle. Zreszta z jednym z informatyków wszystkie ich serwisy teraz powoli przerabiamy, bo jeszcze pod php4 chodzą, a sam sposób pisania woła o to by serwisy dobić i przepisać od nowa (IMG:style_emoticons/default/winksmiley.jpg)