Spore forum po przesiadce na VB4 - przemyślenia odnośnie wydajności i odzew supportu

[marecek]

Witam,
Jest to mój pierwszy post na forum i chciałbym od razu przejść do kwestii przesiadki z VB 3.8.4 na VB 4.0.2, co by za wczasu przestrzec przed ewentualnymi problemami.

Administruję serwerem, na którym utrzymywane są dwa sporych rozmiarów fora vb (5000 uników i 20 000 uników dziennie), obydwa w najnowszych wersjach dostępnych 3.8.4. Fora te generują 95% obciążenia serwera (pozostały ruch to drobne strony, głównie statyczny kontent, jedno forum phpbb o niskiej odwiedzalności). Maszyna ma spory potencjał, 4GB pamięci, 64 bity na dual core X2 AMD, ale przy obecnym kształcie baz danych powoli przymierzam się do przesiadki na sprzęt o dwukrotnie wyższej specyfikacji ze względu na rozmiar baz dochodzący powoli do 1,5 GB każda.

W grudniu padła decyzja o przyjrzeniu się możliwościom VB4 na środowisku testowym. Udało się pomyślnie przeprowadzić migrację danych, przenieść wszystko na środowisko działające "z boku". Wpuściliśmy użytkowników, zebraliśmy dość pozytywny feedback i czekaliśmy na wersję GOLD z przesiadką. Ponieważ cały czas były głosy o tym, że nie działają różne "wtyczki", a to shoutbox się nie podobał użytkownikom, a to grafika, a to milion innych powodów... czekaliśmy aż uda nam się odwzorować oczekiwaną funkcjonalność na nowym silniku.

Udało się. Kilka dni temu przeprowadziliśmy kolejny udany upgrade na środowisku testowym, dwie próby pomyślnie, przygotowaliśmy skrypty do migracji, wyłączyliśmy forum na godzinę, wcisnęliśmy czerwony przycisk i nacisnęliśmy wajchę - na "pierwszy ogień" poszło duże forum. Pełen backup bazy, plików, nadpisanie plików, odpalenie skryptów - znacie procedurę...

...ta noc i dzień po były najdłuższymi w życiu administratora forum (ja osobiście jestem odpowiedzialny za utrzymanie sprzętu oraz fizycznie za drugie - nie zmigrowane jeszcze fourm).

Jak tylko ludzie zaczęli pojawiać się na forum, transfer skoczył o 70%. Apache co chwilę generował maksymalną ilość klientów, nie będąc w stanie w sensownym czasie obsłużyć odpowiedniej ilości zapytać. Co ciekawe - ilość zapytań SQLa wyraźnie spadła w związku z tym, że apache nie nadążał z dostarczaniem zapytań. Pytanie brzmi dlaczego? Aktualna konfiguracja apache-a jak i bazy mysql została wypracowana przez lata doświadczeń i podążania za trendami optymalizacyjnymi dla tego rodzaju rozwiązań. Przesiadka na VB4 sprawiła, że wszystko stanęło w miejscu...

Cały problem polega na tym, że nie ma możliwosci tego tak naprawdę zweryfikować, dopóki nie przerzuci się całego obciążenia z forum testowego na forum "produkcyjne" - bo niby jak? W labie wszystko działa płynnie, szybko i bez najmniejszych problemów. Jak wpuścimy 1500 użytkowników na raz, zaczynają się poważne problemy z obsługiwaniem requestów...

Dla porównania transfer z dnia poprzedzającego przesiadkę i "czarnego wtorku":

Feb22


Feb23


o godzinie 10.00 ilość przesyłanych danych osiągała takie wartości, jak w normalny dzień w porze maksymalnego obciążenia 21.30. Niestety, dane te nie odzwierciedlają zapewne rzeczywistych możliwości vb4, bo apache "leżał" i nie obsługiwał requestów średnio 15 minut w ciągu godziny (przyprawiając mnie przy okazji o ból brzucha z nerwów).

Poniżej screnshot obciążenia CPU z wczoraj w porze największej odwiedzalności (skala 200% przyjęta dla oznaczenia dwóch rdzeni)



na obrazku widać obciążenie jakie występowało w tym czasie. Dla porównania - dzienny max nie osiągał do tej pory 120% CPU "w peaku" największej aktywności i było to bardzo przewidywalne (czytaj: do tej pory działało poprawnie i dawało się szacować jakieś trendy wzrostu obciążenia w czasie).

W chwili obecnej forum zmigrowane do VB4 działa w trybie "read only". Na drugim forum plany "przesiadki" odsunięte zostały na "wieczne nigdy". Zgłoszony został ticket do VB oraz oficjalny request na optymalizację serwera - czekam na oficjalne stanowisko. Jeśli dostaniemy informację o tym, że "tak powinno być", to wracamy z kopią zapasową z wtorku i cieszymy sie 3.8.4...

Celem tego postu nie jest obrzucanie błotem możliwości skryptu VB, który wg mnie jest genialny! Chodzi tylko o to, żeby nie wpuścić w kanał i nie zostawić na lodzie osób, które zainwestowały pewną sumę pieniędzy w profesjonalne rozwiązanie, które może okazać się jednym wielkim problemem kiedy przyjdzie do aktualizacji...

Pytanie brzmi: jakie nowe "ficzery" VB4 uzasadniają taki krok wstecz?!

[RadioErewan]

Hehe, oni to nazywaja code refactoring, co by to miało nie być. Jaskółką nowego trendu jest CMS, który na wyświetlenie linijki tekstu potrzebuje sześciu zapytań SQL.
Może spróbujcie wyłączyć większość wodotrysków. Zaczynając od CMS. Na vb.com jak odpalali w listopadzie swojego vB4, wyłączyli prawie wszystko. Po pewnym czasie vB się nawet ustabilizował.

[jedrus]

Mamy wyłączone:
CMS
BLOG

działa tylko forum

[RadioErewan]

No cóż. To tylko podsyca moje mocne postanowienie pozostania na 3.8.4. Więcej ci nie pomogę.
Ale... Czy w trybie read only strona działa? Ta ilość transferu wynikała pewnie z tego, że każdy z 5000 userów musiał pobrać te 20 plików CSS, które generuje skrypt. Efekt nowości. Na Read Only obciążenie jest nadal tak duże?

[jedrus]

Tak, niestety load serwera nadal jest wysoki. Siłą rzeczy jednak siedzi na forum mniej użytkowników i mniej intensywnie z niego korzystają.

Mimo to, obciążenie:

top - 12:32:55 up 33 days, 25 min, 1 user, load average: 3.48, 2.83, 2.47
Tasks: 291 total, 3 running, 287 sleeping, 0 stopped, 1 zombie
Cpu0 : 87.7%us, 7.5%sy, 0.0%ni, 3.8%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Cpu1 : 85.0%us, 3.7%sy, 0.0%ni, 11.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4021144k total, 3969988k used, 51156k free, 66792k buffers
Swap: 2104504k total, 963344k used, 1141160k free, 1127436k cached

[meschiash]

Potwierdzam również, znacznie większe obciążenie serwera i transferu. U mnie przejście na vB4 było konieczne ponieważ realizuję projekt, którego nie ma sensu pisać na vb4 a potem przepisywać na vb4. Gryzę codziennie tą cytrynę i wstaję ze sztucznym uśmiechem.

[trzepiz]

Potwierdzam znaczny spadek wydajnosci vb4 do poprzednika z serii 3. Również obserwuję znaczny spadek (przede wszystkim) szybkosci działania forum (również spora ilosc userów). W porównaniu do wersji 3 .. vb4 jest zdecydowanie wolniejsze .... oraz generuje większy transfer.

[Seba]

Hey.

Zaciekawiony Twoim tematem postanowiłem odpowiedzieć

Głównym Twoim problemem jest iowait - dochodzi on do 100%. Dla mnie niedopuszczalnym %wa jest wartość ponad 10, więc zanim przemyślisz zmianę sprzętu rozwiąż problemy dyskowe - możliwe że RAID pomoże, bądź po prostu zmiana wysłużonych SATA'owskich dysków na SAS / SSD.

Ponadto popatrz na konfigurację mysql, jestem pewien iż to on dociska HDD do kresu ich możliwości. Zerknij też na slowqueries, może coś ciekawego wyczaisz.

Piszesz również o Apache i maxclients - ile userów online było, jak ustawione dyrektywy w configu ? Coś mi się tu nie podoba, bo na podobnym sprzęcie, o prawie identycznym ruchu i w szczycie 800-900 online Apache wyrabiał bezproblemowo, iowait na poziomie max 5. W jakim trybie masz ustawione php, fastcgi czy mod_php ?

Zainteresuj się teź lighthttpd / ngix bądź płatnym zamiennikiem Apache - litespeed, sam używam i szczerze polecam.


To co piszesz jest wręcz niewiarygodne, Twoje zastrzeżenia zaprzeczają stwierdzeniu

Aktualna konfiguracja apache-a jak i bazy mysql została wypracowana przez lata doświadczeń i podążania za trendami optymalizacyjnymi dla tego rodzaju rozwiązań.

Pzdr.

[marecek]

Seba, dzięki za spostrzeżenia. Faktycznie głównym problemem jest iowait. Serwer utrzymuję hobbystycznie, a nie "profesjonalnie", a stwierdzenie o latach doświadczeń opieram jedynie tym, co udało mi się poznać czytając fora optymalizacyjne dla skryptów typu vb. Prawda jest taka, że po powrocie do 3.8 serwer pracuje bardzo spokojnie, statystyki transferu wróciły do "normy" a ładowanie stron odbywa się z taką prędkością, jakby serwer nie stał pod Frankfurtem, tylko na moim dysku lokalnym...

I nie wydaje mi się, żeby jakakolwiek optymalizacja coś tutaj dała -> nowy skrypt ma po prostu o wiele większe wymagania i tyle. Celem tego tematu jest zwrócenie uwagi na ten drobny problem, o którym nie wspomina się na forum vb.com. Dla mnie głównym powodem przesiadki na VB była wydajność. W obecnej sytuacji odpadł główny atut tego skryptu... Bo wzrostu używalności czy możliwości forum jako takiego nie widzę nic a nic...!

[Marek]

Hehe, oni to nazywaja code refactoring, co by to miało nie być. Jaskółką nowego trendu jest CMS, który na wyświetlenie linijki tekstu potrzebuje sześciu zapytań SQL.
Może spróbujcie wyłączyć większość wodotrysków. Zaczynając od CMS. Na vb.com jak odpalali w listopadzie swojego vB4, wyłączyli prawie wszystko. Po pewnym czasie vB się nawet ustabilizował.

Jak można teraz wyłączyć CMS skoro był to jeden z głównych powodów zakupienia vB Suite?

Faktem jest że vB4 działa dużo wolniej niż vB3.8, a tak miało być cacy. Miejmy nadzieję że zoptymalizują wreszcie to vB4 i kasa wydana na jego zakup nie okaże się wyrzucona w błoto. Ja osobiście żałuję przesiadki na vB4 bo kosztuje to teraz sporo roboty a efekty są mizerne. W dodatku nie ma porządnej skórki do vB4. Wszystkie jakie znalazłem są do kitu. Darmowe zawierają bardzo dużo błędów, a profesjonalne swoim wyglądem nie zachęcają do zakupu. W 3.8 miałem zakupioną Arię. Niestety - pomimo posiadanej na nią licencji ważnej do lipca tego roku - nie mogę z niej skorzystać pod vB4 bo jej autor bardzo się ślimaczy z aktualizacją dla vB4.
W sumie to nie ma co się dziwić autorom skórek że nie śpieszą się z aktualizacją skórek bo vB4 w dalszym ciągu wymaga dużych zmian, a więc i podobnie jest ze skórkami.