Temat: Symulowanie duzego ruchu

Witam,
Jestem w trakcie testowania systemu korzystajacego z Amazon AWS ktory ma obsluzyc 1 godzinne wydarzenie marketingowe w necie o bardzo duzym ruchu (spodziewane ok 50tys uzytkownikow) i spotkalem sie z oporem ze strony narzedzi AB i SIEGE odczas symulacji ktore zwracaja bledy limitu plikow i limitu socketow podczas gdy webserwery nie wygladaja na specjalnie obciazone. Gdzie robie blad?

Konfiguracja:

1 x AWS Load balancer (stickiness disabled)

1 x AWS instance (db serwer)
serwer to CentOS: High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

3 x AWS instance (web serwer)
- kazdy serwer to CentOS: High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform
- apache prefork, php5.3.3 modul, mysql5.1.47

Test:
Testowana jest prosta strona www, 1 strona ktore poprzez requesty ajaxowe bedzie odswiezac kontent via json z bazy, requesty sa krotkie ok 200-300 znakow w json z bazy, zapytania do bazy max 3 na jeden request wykonuja sie ponizej 0,002s, poprawne indeksy na myisam

> ab -c 1000 -n 20000 http://url.com
> siege -b -c 1000 -r 200

po wykonaniu powyzszych komend z c=1000 otrzymuje ok 3000request/s z failure=0, kazdy wzorst c wiekszy niz 1000 daje ponad 25% failures i ani ab ani siege nie moze zakonczyc poprawnie testowania, w obu przypadkach zwraca blad: ...: Too many open files

zwiekszylem limit plikow do 2048 z 1024 i tym razem wyrzuca blad ogolny ...: Socket error

Podsumowujac:
Jak zasymulowac tak duzy ruch na serwerze w celu oszacowania ile web serwerow musze podpisac pod load balancer dla danej strony www. W moim przypadku widze jak na dloni ze webserwery nie sa zbytnio obciazone, db server tez sie nudzi a ab i siege wyrzucaja bledy i bad requesty...

zrzut z ab z proba c=4000 na public url load balancera:

[root@ip ~]# ab -c 4000 -n 70000 http://url.com/news
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking http://url.com.amazonaws.com (be patient)
Completed 7000 requests
Completed 14000 requests
Completed 21000 requests
Completed 28000 requests
Completed 35000 requests
Completed 42000 requests
Completed 49000 requests
Completed 56000 requests
Completed 63000 requests
Finished 70000 requests


Server Software:
Server Hostname: http://url.com.amazonaws.com
Server Port: 80

Document Path: /news
Document Length: 0 bytes

Concurrency Level: 4000
Time taken for tests: 56.43387 seconds
Complete requests: 70000
Failed requests: 56066
(Connect: 0, Length: 56066, Exceptions: 0)
Write errors: 0
Non-2xx responses: 12067
Total transferred: 847796346 bytes
HTML transferred: 832600357 bytes
Requests per second: 1249.03 [#/sec] (mean)
Time per request: 3202.479 [ms] (mean)
Time per request: 0.801 [ms] (mean, across all concurrent requests)
Transfer rate: 14772.95 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 749 2744.4 3 45026
Processing: 0 1649 3912.4 313 55346
Waiting: 0 999 3376.1 77 52709
Total: 1 2398 4944.9 406 55376

Percentage of the requests served within a certain time (ms)
50% 406
66% 1453
75% 3042
80% 3329
90% 6597
95% 10124
98% 21058
99% 26126
100% 55376 (longest request)

Z gory dziekuje za sugestie i wskazanie gdzie robie blad
pozdrawiam

Temat: Symulowanie duzego ruchu

zwracaja bledy limitu plikow i limitu socketow podczas gdy webserwery nie wygladaja na specjalnie obciazone. Gdzie robie blad?

Nie potrzeba obciążenia żeby wyczerpać domyślny limit 1024 otwartych plików, socket też potrzebuje deskryptora pliku więc wpada w ten limit.
uname -n i limits.conf Twoim przyjacielem. Ewentualnie używaj epoll'a zamiast select'a bo ten pierwszy jest właśnie do tego zaprojektowany aby radzić sobie z dużą ilością jednoczesnych połączeń.

P.S. wyłącz też keepalive'y to zaoszczędzisz na wiszących otwartych połączeniach.Łukasz M. edytował(a) ten post dnia 30.07.10 o godzinie 19:35

Temat: Symulowanie duzego ruchu

Łukasz M.:

zwracaja bledy limitu plikow i limitu socketow podczas gdy webserwery nie wygladaja na specjalnie obciazone. Gdzie robie blad?

Nie potrzeba obciążenia żeby wyczerpać domyślny limit 1024 otwartych plików, socket też potrzebuje deskryptora pliku więc wpada w ten limit.
uname -n i limits.conf Twoim przyjacielem. Ewentualnie używaj epoll'a zamiast select'a bo ten pierwszy jest właśnie do tego zaprojektowany aby radzić sobie z dużą ilością jednoczesnych połączeń.

P.S. wyłącz też keepalive'y to zaoszczędzisz na wiszących otwartych połączeniach.

dzieki za sodpowiedz

w limits.conf mialem juz ponizsze wpisy ktore wyeliminowaly blad "Too many files open" domsylnie ustawiony na 1024, ale pojawily sie bledy socketow ktorych wczesniej nie bylo, nawet ustawienie na 20000 nic nie zmienia
root soft nofile 10000
* hard nofile 10000

sam mysql nie jest tu problemem poniewaz przy testowaniu statycznego pliku HTML lub pliku PHP bez mysql bledy sa identyczne - mysql jest mocno zoptymalizowany i sprawdzany cylicznie za pomoca narzedzi mysqltuner (perl) i mysqlreport (sh)
domyslam sie ze keepalive to sugestia do zmiany konfiguracji mysqld ?

nie wiem gdzie zmienic limit max socket na uzytkownika, w w manualu nie widze tej opcji http://linux.die.net/man/5/limits.conf
maszyna ma 64GB ramu i bardzo silny CPU wiec wydaje mi sie ze mozna by to zwiekszyc?Arkadiusz K. edytował(a) ten post dnia 30.07.10 o godzinie 20:04

Temat: Symulowanie duzego ruchu

mam rowniez podejrzenia ze to specyfika testowania przez ab i siege, poniewaz uruchomilem siege na 3 innych maszynach poza chmura aws z parametrem c=1000 czyli lacznie 3000 atakowaly load balancer - w rezultacie otrzymalem identyczne bledy, bylo ich troche mniej i wiecej prob sie udalo ale dalej wystepowalyArkadiusz K. edytował(a) ten post dnia 30.07.10 o godzinie 20:04

Temat: Symulowanie duzego ruchu

limity musisz ustawić dla wszystkich userów którzy mają mieć dużo otwartych plików, każdy używany socket == otwarty plik. Zrób to i na serwerach www i na load balancerze, mysql pewnie jeszcze nie jest wąskim gardłem więc się nim nie przejmuj. Moc maszyn będzie miała znaczenie wtedy kiedy zaczną coś liczyć, czyli jak php/ruby/python/perl/whatever zacznie coś renderować, teraz Twój problem polega prawdopodobnie na tym, że Twoje serwery nie pozwalają na zbyt wiele jednoczesnych połączeń do nich.
keepalive - opcja dla serwera www albo load balancera jeśli działa w tej warstwie (np. haproxy), nie wiem co jest na aws'ie
poza tym dotunować trzeba jeszcze parametry jajka, przede wszystkim stos tcp, poczytaj w dokumentacji haproxy o przydatnych sysctl'ach, tak na szybko to spróbuj

net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65023
net.ipv4.tcp_max_syn_backlog = 10240
net.ipv4.tcp_max_tw_buckets = 400000
net.ipv4.tcp_max_orphans = 60000
net.ipv4.tcp_synack_retries = 3
net.core.somaxconn = 10000

wyładuj też moduły iptables jeżeli nie używasz na backendach firewall'a, a przynajmniej te od conntracka'a.

Temat: Symulowanie duzego ruchu

Łukasz M.:

male zmiany w konfiguracji i wyniki wygladaja juz lepiej, udalo sie zmienic dla wszystkich userow file limit na 65k, niestety nie chce wziac wiekszego ani unlimited ale poki co wystarczy chyba

w tej chwili SIEGE i AB zwracaja lepsze wyniki bez bledow z FILE LIMIT i SOCKET ERROR dla php bez mysql (z mysql sa nieco gorsze ale i tak dobre)

Teraz jedyny blad jaki otrzymuje pochodzi pradopodobnie z apache'a => apr_socket_recv: Connection reset by peer (104)

Wydaje mi sie ze albo osiagnalem limit maszyny, albo trzeba cos potuningowac z httpd.conf
wg AB c=5000 (max 1550requests/s)
wg SIEGE c=2200 (max 3200requests/s)

aktualna konfiguracja prefork to (dla testow egzotyczne limity):

<IfModule prefork.c>
StartServers 64
MinSpareServers 64
MaxSpareServers 600
ServerLimit 10000
MaxClients 10000
MaxRequestsPerChild 40000
</IfModule>

BTW
iptables = wylaczone
ip_conntrack = wylaczone
load balancer jest wirtualny w AWS, nie ma do niego zadnych opcji oprocz dodania nowych instancji "on-fly"

[root@ip ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 560064
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 560064
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

* ponizej wyniki wszystkich testow:

=====================================
=AB ERROR============================
=====================================

[root@ip ~]# ab -c 8000 -n 10000 http://url.com/news
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking compute-1.amazonaws.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
apr_socket_recv: Connection reset by peer (104)
Total of 7975 requests completed

=================================
=AB OK ==========================
=================================

root@ip ~]# ab -c 5000 -n 5000 url.com/message
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking compute-1.amazonaws.com (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Finished 5000 requests

Server Software: Apache
Server Hostname: compute-1.amazonaws.com
Server Port: 80

Document Path: /message/db
Document Length: 4001 bytes

Concurrency Level: 5000
Time taken for tests: 3.222864 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 21980077 bytes
HTML transferred: 20697173 bytes
Requests per second: 1551.42 [#/sec] (mean)
Time per request: 3222.864 [ms] (mean)
Time per request: 0.645 [ms] (mean, across all concurrent requests)
Transfer rate: 6659.92 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 359 836.2 97 3011
Processing: 3 268 106.8 269 536
Waiting: 0 172 90.1 189 375
Total: 164 628 775.5 385 3133

Percentage of the requests served within a certain time (ms)
50% 385
66% 390
75% 399
80% 472
90% 588
95% 3096
98% 3098
99% 3098
100% 3133 (longest request)

=====================================
=SIEGE OK============================
=====================================

Lifting the server siege... done.
Transactions: 12222 hits
Availability: 98.54 %
Elapsed time: 4.72 secs
Data transferred: 15.07 MB
Response time: 0.23 secs
Transaction rate: 2589.41 trans/sec
Throughput: 3.19 MB/sec
Concurrency: 600.94
Successful transactions: 12222
Failed transactions: 181
Longest transaction: 2.13
Shortest transaction: 0.00
/home/siege/bin/siege -c 2200 -r 100

dziekuje za wskazowki, chetnie wyslucham rowniez sugestii o tuningu apache'a

Temat: Symulowanie duzego ruchu

Arkadiusz K.:
dziekuje za wskazowki, chetnie wyslucham rowniez sugestii o tuningu apache'a

Najlepszy tuning apacha jaki znam to zainstalowanie nginx'a albo lighttpd

Temat: Symulowanie duzego ruchu

Łukasz M.:
Najlepszy tuning apacha jaki znam to zainstalowanie nginx'a albo lighttpd

To jeszcze zależy od technologii samej aplikacji webowej. Często apache uzyskuje lepsze wyniki dla php. Jednak nie jest to regułą. Można spróbować zainstalować nginx'a i użyć dużej liczby procesów php po fcgi (wtedy load balancing między procesami php jest automatyczny).

Temat: Symulowanie duzego ruchu

Łukasz M.:
Najlepszy tuning apacha jaki znam to zainstalowanie nginx'a albo lighttpd

masz racje ale.. system do obslugi tego wydarzenia jest juz napisany (php5.3.3), wymagaloby to przerobek i usuwania htaccess, nie wspomne o testach na fastcgi i modulow lighttpd ktorych po prostu nie znam tak dobrze jak modulow apache'a gdzi e wiem czego sie mniej wiecej spodziewac na serwerze produkcyjnym

moje pytanie na ta chwile to jak ustawic config apache'a zeby nie limitowal niczego (max clients, max servers itp itd) poniewaz wyglada mi na to ze limit maszyny nie jest wykorzystany a blad "connection reset by peer (104)" wynika wlasnie z jednego limitu configa (lub z limitow ab i siege?)

jednym slowem chce miec pewnosc ze serwer padnie z braku pamieci lub CPU naturalnie a nie przedwczesnie z powodu limitow apache'a, potrzebne mi jest to do dokladnego oszacowania max requestow na maszyne - przypomne jest to 64GB i 8 core CPU czyli najsilniejsza instancja amazona

moze sie myle ale nawet jak ustawie limity zbyt blisko granic wytrzymalosci maszyny i serwer padnie z powodu tego braku zasobow to load balancer wykryje ten pad i automatycznie przekieruje request na inna instancje

na chwile obecna wychodzi mi ze bede potrzebowal 20-25 instancji amazona do obslugi 50k requestow w szczycie chcialbym jednak wykonac ten test poprawnie

Artur Smęt:
To jeszcze zależy od technologii samej aplikacji webowej. Często apache uzyskuje lepsze wyniki dla php. Jednak nie jest to regułą.

rowniez znalazlem testy w necie potwierdzajace ze apache2+php ma ok 20% lepsze wyniki niz lighthttp+php ale wyniki tu najpewniej zaleza od tego jak wyglada aplikacja php

Można spróbować zainstalować nginx'a i użyć dużej liczby procesów php po fcgi (wtedy load balancing między procesami php jest automatyczny).

mam caly statyczny content na CDN amazona wiec u mnie 1 strona = 1 request ktory jest php, nie wiem czy w tym przypadku nginx jest najlepszym wyborem, wlasciwie sprawa rozbija sie ponownie o php

pozdrArkadiusz K. edytował(a) ten post dnia 02.08.10 o godzinie 17:39

Temat: Symulowanie duzego ruchu

Arkadiusz K.:

Artur Smęt:
To jeszcze zależy od technologii samej aplikacji webowej. Często apache uzyskuje lepsze wyniki dla php. Jednak nie jest to regułą.

rowniez znalazlem testy w necie potwierdzajace ze apache2+php ma ok 20% lepsze wyniki niz lighthttp+php ale wyniki tu najpewniej zaleza od tego jak wyglada aplikacja php

Tak tylko że apacha trzeba dobrze stuningować do tego ;]. Apache z mpm_event + php przez fastcgi jest porównywalny prędkością z ligty/nginx, przegrywa natomiast przy plikach statycznych ale skoro masz na amazonie to nie problem ;].

Z moich doświadczeń, liczba procesów phpa = liczba rdzeni * 2 (chyba że aplikacja większość czasu spędza czekając na to, wtedy więcej).

Nie wiem jak wygląda balancing amazonowy, ale na haproxy ustawiałem żeby max. ilość połączeń na backend nie była dużo większa niż ilość procesów PHPa, tak że requesty kolejkują się na haproxy a nie na samym serwerze, ma to tą zaletę że po pierwsze apache nie musi obsługiwać tylu czekających połączeń (a nie jest w tym zbyt dobry) a po drugie gdy kolejka jest na balancerze to może on je przydzielać je do "pierwszego wolnego" serwera, obciążenie się bardziej równomiernie rozkłada