Benchmark CMSów i For pod obciążeniem

Za pomocą httperf przetestowałem kilkanaście popularnych skryptów CMSów i for dyskusyjnych. Porównywanym czynnikiem był uśredniony czas wykonywania testu (3 próby). Sam test polegał na wykonaniu 20 połączeń i wysłanie 5 żądań strony głównej skryptu. Dzięki zastosowaniu httperf możliwe było uzyskanie danych dotyczących wydajności skryptu pod obciążeniem.

Sprzęt i oprogramowanie

Acer Aspire 5002 WLMi, 512MB DDR, AMD Turion64 ML-30. Gentoo Linux amd64, serwer cherokee 0.5.6, php-5.2.0 z suhosin, MySQL 5.0.32 (używano interfejs MySQLi wszędzie tam gdzie możliwe). Testowane skrypty to standardowe instalacje, za wyjątkiem kilku skryptów, gdzie musiałem dodać przykładowe dane czy w przypadku Postnuke 0.7 ustawić skórkę Xanthia.

Zestawienia Wyników

Czas trwania testu - 20 połączeń po 5 żądań
Skrypt Czas trwania testu (s)
Aplikacja Django 2,3
punBB 1.2.14 2,93
PHP-Fusion 6.01.6 3,01
txtBB 1.3.rc3 3,46
Guppy 4.5.17 3,68
phpBB 2.0.22 3,97
4images 1.7.4 4,46
e107 0.7.7 4,70
SMF 1.1.1 4,93
Coppermine Gallery 1.4.10 5,12
phpBB by Przemo 1.12.5 5,28
Joomla 1.0.12 5,98
Wordpress 2.1 6,00
Drupal 5.0 6,05
Mambo 4.6.1 6,44
Postnuke 0.764 7,57
Postnuke 0.800 MS 2 7,71

Gdzie Aplikacja Django to "Biblioteka CMS" na serwerze deweloperskim Django używająca PostgreSQL 8.1.5 ("mniej" wydajne od Cherokee+SCGI). Skrypty wykonujące się szybciej zużywały więcej czasu procesora (49% punBB, 24.3% Postnuke 7). Szybsze skrypty zużywały więcej czasu procesora, gdyż "realizowały" większą ilość połączeń na sekundę (6.4 połączeń/sek. dla punBB i 2.7 połączeń/sek. dla Postnuke 7). W teście ostatnie miejsce zajął Postnuke ale to tylko dla tego iż nie ma MD-Pro, które w poprzednich testach zajmowało wspomniane ostatnie miejsce.
htbench_1


Testy a Wydajność

Wspomniany test jak każdy nie odwzorowuje w pełni wydajności aplikacji. W powyższych testach stosowano skrypty bez dużej ilości danych, ani nie mierzono ruchu z serwera MySQL co jest równie ważne. Drupal czy Wordpress nie są najszybsze w powyższym teście lecz skrypty te są z powodzeniem stosowane na wielu stronach poddawanych potężnym obciążeniom. Czas generowania strony głównej skryptu bez danych jest proporcjonalny do ilości kodu PHP. Kluczowe elementy odpowiedzialne za skalowalność to zapytania baz danych oraz parsowanie szablonów (wolne Xanthia i AutoTheme ratuje keszowanie).
Postnuke 0.764 posiada błąd w zapytaniu używanym do wygenerowania odnośników stronicujących newsy na stronie głównej. Owy błąd polega na tym iż pobierane są wszystkie dane newsów i po ich pobraniu liczona jest ich ilość. W przypadku np. tysiąca czy większej ilości newsów zapytanie to generuje widoczne obciążenie a w przypadku, gdy serwer MySQL jest na oddzielnej maszynie - bardzo duży ruch między tą maszyną a maszyną z serwerem HTTP. Wspomniany błąd jest dobrze znany na polskiej stronie post-nuke.pl (przeciążanie serwerów) lecz o dziwo nie został zgłoszony deweloperom postnuke :omg:
Czas trwania testu - 20 połączeń po 20 żądań, 3000 newsów
Skrypt Czas trwania testu (s)
PostNuke 8.5
Postnuke + Stronicowanie 10.37

Jest też prawdopodobne że któryś z dodatków phpBB by Przemo również zawiera jakieś niezoptymalizowane zapytanie SQL jako że też dość często są z nim problemy ("przeciążanie serwera") o czym można poczytać na forum webhostingtalk.pl.
RkBlog

Podstawy tworzenia stron www, 11 July 2008

Comment article
Comment article RkBlog main page Search RSS Contact