Linux за българи: Форуми

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


тук

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

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

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

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

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

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

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

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

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

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

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

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

Цитат

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

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

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

Правих първият тест с 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, ще видим какво ще излезе.

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

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

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

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

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

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

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

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

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

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

Здравейте,

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

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

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

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

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

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

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

Здравейте,

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

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

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

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