Изпечатай

[gat3way]

Както писах в една тема, тая вечер направих малко тестове:


тук

тестовете си имат и слаби места, поради това че идеята ми дойде спонтанно и не беше обмисляна повече време, но както и да е, надявам се че ще е полезно. Драскайте коментари ако имате идеи по въпроса '>

[zeridon]

Хмм интересни резултати определено. Стилът не е много добър но то на кой ли му е добър стилът на писане.

Лично на мен ще ми е интересно да видим още малко статистики а именно:
 * Disk  Utilisation
 * Има ли ефект ако статичното съдържание се сервира от рамдиск
 * има ли ефект от syncookies

Предполагам че си попадал на:
 http://linuxgazette.net/123/vishnu.html
 http://www.clipclip.org/clips....wnloads

[gat3way]

Оф,да, много бързах да го докарам до някакъв завършен, при това вече бях на няколко бири, ще го изчиствам впоследствие.

Горните сайтове не съм ги виждал, други работи бях гледал '>

Що се отнася до дисковата утилизация, нямаше да е лоша идея наистина. За рамдиска...ммм със сигурност ще има разлика, но според мен веднъж когато сервираният файл се качи в кеша на ядрото, няма значение особено. С динамичното съдържание е по-забавно де, там не знам. За syncookies нямам идея.

Мене повече ме е яд че примерно не го тествах срещу примерно някаква joomla, както и срещу статично съдържание - голям файл, примерно няколко гигабайта, колкото кеширането да не го лови.

[Йордан]

За съжаление не мога да се съглася с резултатите от теска - според мен nginx в реално условия пребива отвсякъде apache.

Моя опит показва, че няма смисъл да се сервира от ramdrive т.к. ако имаш контент по-малко от паметта на машината той си се кешира от самата операционна система. Също така в nginx има редица оптимизации по повод на извикването/поискването на файловете.

Лично аз съм много доволен. Бих препоръчал lighttpd да се добави в тестваните приложения - много интересни резултати показва последната версия

[gat3way]

Отговорих там преди да видя и че си писал и тук '> Ще копи-пейстна де, че ме мързи '>

Цитат

Действително, nginx троши доста по-малко процесорно време, не съм следял постоянно какво става по време на тестовете, но грубо казано рядко съм го виждал да взема повече от 10-20% процесорни ресурси. Apache от друга страна, независимо дали с prefork или worker, товареше доста повече процесора, което е нормално - все пак се вдигат до 256 процеса/нишки при тестовете. Въпреки това, bottleneck-а при сервирането на заявките не съм убеден че е свързан с CPU starvation. Самото сервиране на съдържание не е толкова CPU-интензивен процес, колкото I/O-интензивен. Има прекалено много четене от диска и четене/писане по мрежовите сокети. В случая с динамичното съдържание и най-вече mysql заявките, това е още по-силно изразено. Поради това, моята теория е че по-големият паралелизъм в apache (там има много процеси и нишки, а не се обслужват всички заявки в рамките на един процес/нишка) утилизира по-добре I/O-то. В този ред на мисли, вече съжалявам, че не пуснах всички тестове с nginx с по-голям брой worker-и (например 20) за да видя какво ще се случи. Което мога да кажа със сигурност е че тогава щеше товари процесора доста повече '> Освен което, тестовете са до първата пропаднала заявка. Напълно е възможно при повече паралелни заявки, в един момент процентът на пропадналите заявки при apache да скача рязко в сравнение с nginx, но просто не ми е била целта да изследвам точно това - аз исках да изследвам до първата пропаднала заявка въобще.

[Йордан]

Сложи 4 работни процеса и ще видиш хубав резултат. Повече от 8 нямат смисъл и трошат яко ресурси.

Иначе за сокетите съм съгласен.

[gat3way]

Правих първият тест с png картинката и и с 2 и с 1 nginx worker-a, но нямаше почти никаква разлика. Трябва да пробвам верно с повече, примерно 4, въпреки че реално трудно се утилизира повече от един процесор, другият е заделен за KVM виртуалната машина, от която пусках пробите. Ще пусна един тест с 4 да видим какво ще излезе. Предполагам малко повече паралелизъм при I/O заявките ще помогне при nginx, както очевидно помага при apache.

Значи аз имах няколко очаквания, свързани и с един прословут документ (the C10K problem). И някои от тях не се оправдаха, но пък вече имам някакво обяснение по въпроса '>

1.  Context switch-овете очевидно не излизат толкова фатално скъпи '> Поне не със сносен процесор (AMD Athlon 64  Dual Core  5200+) и с бързичка DDR2 памет. На по-бавен процесор и по-калпава РАМ, предполагам постоянното превключване между 255 apache  процеса се превръща в bottleneck.

2. Всички ядра за amd64 и по-новите за x86 са компилирани с HZ=1000, а не HZ=100. Това означава, че timeslice-a e 1ms, а не 10ms. Ерго, ако има 2 процеса, които се бият за процесорно време и не "блокират" някъде, вторият процес с голяма вероятност ще се schedule-не доста по-бързо. Това увеличава паралелизма.

3. sendfile() се използва вече и в apache, не знам дали това е от 2.0.нещо си или от 2.2.нещоси.

4. При event I/O-тата "мултиплексирането" става в рамките на процеса. Накратко  един цикъл с epoll_wait() и ако има събитие на някой сокет от set-a се вика функцията която го обслужва. При apache ролята на този механизъм се извършва от ядрото, т.е когато на някои от сокетите, асоцирани с някой apache процес се случи нещо, task scheduler-a "събужда" процеса и го слага в runqueue. Но не мога да кажа кой от двата варианта е по-добър: в случаят с epoll() имаш по-малко context switching, във вторият случай вероятно имаш по-добър паралелизъм.


Както и да е, ще повторя теста с 4 nginx worker process-a, ще видим какво ще излезе.

[gat3way]

Мммм, пуснах същите тестове с 4 worker-a. Значи response time-a при статичното съдържание падна повече от 2 пъти и стана по груби сметки малко по-добре от това при апача (не съм чертал графики, по стойностите се ориентирам).

При динамичното съдържание, разлики почти нямаше, малко по-нисък response time.

Това, което остана едно и също (не очаквах да стане честно казано) е че първата отказана заявка си се случи на същото място на всички тестове.

Значи това, което ме нервира е че тези тестове се правят въз основата на много елементарни и прости сценарии като идеята е да се отсеят повечето странични фактори.

Мисля да направя нещо като версия 2 на теста - ще го тествам върху реално уеб приложение (и ще има доста отклонения в резултатите и ще трябва да осреднявам повече проби за жалост).

[gat3way]

Апропо, намерих единият сайт, за който говорих:

http://www.sthoughts.com/?p=329

[Йордан]

Още едно уточнение. Спъни сървиса примерно във виртуална машина и тествай от яко желязо с няколко ab примерно. Ти май правиш обратното?

[gat3way]

А, не. Може де, но няма много смисъл от операцията. Със сигурност ако го бях изтрещял с по-голям общ брой конекции и по-голям брой едновременни такива, ресурсите на системата, откъдето тествам щяха да се изчерпат и тогава щях да тествам клиента реално, а не сървъра '> Дали сървърът може да поеме повече конекции? Определено може, може би поне още толкова, може и в пъти повече - не знам. Колко от заявките ще се обслужат за повече време от 5-секундния таймаут или няма да се обслужат въобще е отделен въпрос. Ако реша да проверя това, мисля, че настоящата тестова постановка няма да ми свърши работа и ще ми трябва още една мощна машинка поне с 2 процесора за целта.

Да го онагледя по по-нормален начин: все едно тествам с един автомат да стрелям по 3 различни тухлени стени. Целта на теста е да се определи след колко изстрела, стената поне на едно място ще бъде пробита изцяло "от-до". А не да я поломя и да я направя на решето. За целта може би един автомат няма да ми свърши работа и ще трябва да пробвам с по-мощни патрони...или пък с базука мухаха.

[bnight]

Здравейте,

Да изкажа и аз мнение като цяло постановката ти на тестовете е що годе нормална.

Правил съм перформанс тестове на следните варианти Apache(suexec,mod_php,fastcgi) и на Nginx като се сервира изцяло динамично съдържание. При това теста е в реално време на продукшън машина за динамично съдържание най-добрият резултат се оказа Apache (mod_php) поне от това което аз тествах де. Мисля си че би било добре да направя и аз някакви нови тестове.

Поздрави за идеята.

[bnight]

За да не отварям нова тема.

Гледам че в Apache 2.2.10 има нов MPM: http://httpd.apache.org/docs/2.2/mod/event.html

Дали може да направим някакви performance тестове с него и без него би ми било любопитно да видя как би се отразило това на Performance-a. gat3way специално се обръщам с молба към тебе ако тази тестова постановка от по-горе ти е още налична да тестваш и този вариант на Apache. Предварително ти благодаря за отделеното време.

[gat3way]

Ами аз си затрих тестовата постановка и скриптовете дето чертаят графиките, но може да пробвам. Хм, гледам че и дебиан са направили пакет с това. Би трябвало да се държи като nginx с повече workers, предполагам и двете ползват libevent.

[abadon]

Здравейте,

Да изкажа и аз мнение като цяло постановката ти на тестовете е що годе нормална.

Правил съм перформанс тестове на следните варианти Apache(suexec,mod_php,fastcgi) и на Nginx като се сервира изцяло динамично съдържание. При това теста е в реално време на продукшън машина за динамично съдържание най-добрият резултат се оказа Apache (mod_php) поне от това което аз тествах де. Мисля си че би било добре да направя и аз някакви нови тестове.

Поздрави за идеята.

И аз си правя подобни тестове, само че моя сайт още не е тръгнал и искам преди да стартира официално да имам най-добрия сървър. Най-добрия резултат постигнах с Apache mod_php + eAccelerator . С това допълнение eAccelerator пройзводителността на php-тата ми се вдигна около 9.5 пъти и Nginx-а нямаше никакъв шанс.