Изпечатай

[backi]

Здравейте,
интересуваме, колко броя потребители едновременно могат да се конекнат към Apache Web Server?

Има ли други ограничния и какви при ползване на Apache?

[borovaka]

Ако ти трябва си редактирай конфигурационния файл търсиш MaxClients и слагаш стойност на максималния брой клиенти. Има и други настройки разгледай документацията.

[backi]

Въпроса ми е дали Apache, ще пусне 10 000 потребители едновременно да цъкат по сайта който е върху него (Apache)?

[b2l]

Код:

man ab

[victim70]

Ако е само веб без скриптове и 20000 ще пусне.
Иначе за скриптове зависи от ресурсите на сървера, мрежа и т.н.т.
Напиши си рекурсивен самостартиращ се скрипт и следи ресурса. Като отиде натоварването на 80% на сървера по нататъка нещата са тегави, виждаш колко пъти се е стартирал и ще разбереш колко потребители носи.

[gat3way]

Какво ще рече 10 хиляди потребителя едновременно? 10.000 установени сесии (=логнати потребители там), 10 хиляди HTTP заявки за определено време или 10 хиляди паралелни HTTP заявки?


Забравете apache да сервира 20 хиляди паралелни заявки. Знам че това е hard лимита, но на практика, трудно постижимо е дори 500 едновременни заявки да се обслужат - това би изисквало доста мощен хардуер. С mpm_prefork особено дори и това би било ужасно добро постижение.

При това, говоря за статично съдържание и малки файлчета. Някакви PHP скриптове, които правят заявки до backend база ще понесат значително по-нисък паралелизъм. За който не вярва - да се пробва с httperf - уникално прост начин да DoS-неш кофти size-нати уеб сървъри. Ако направиш грешката да сервираш динамично съдържание и да издъниш MaxClients, някой хубав ден ще завариш машинката тръшната с OOM грешки заради някой шегаджия

Принципно е много трудно да се напише сървър, който да понася такъв висок паралелизъм (хиляди паралелни заявки). При Apache има два варианта - mpm_prefork, който изпълнява отделните заявки в рамките на отделни процеси и mpm_worker, който ги изпълнява в отделни нишки. Процесите са по-"скъпи" от нишките, защото работят в отделни контексти, с отделни адресни пространства и превключването между тях е по-бавно. Отделно комуникацията между тях (IPC-то) е бавна, защото изисква намесата на ядрото и копиране на памет. Друг кофти момент с процесите е че въпреки, че в адресното им пространство може да има мапната обща памет, някои неща си остават private. Колкото повече процеси имаш, толкова повече private данни, ерго толкова по-висока утилизация на паметта...и в един хубав момент физическата памет свършва, почва се page-ване и производителността загива...а може и по-лошо да стане, да свърши и swap-а и тогава става наистина грозно.

С нишките, нещата са малко по-добре, но всяка нишка се конкурира с останалите за процесорно време. Синхронизацията между нишките (понякога) изисква намеса на ядрото, демек не е казано че става светкавично. Гръмването на една нишка води до умирането на целия процес и следователно всички останали нишки в рамките на процеса. Освен което, ако ползваш PHP скриптове - не всички PHP extension-и са thread-safe, в един прекрасен момент, работещ код може да гръмне и затова няма как да си виновен ти.

Големите глави са измислили и друг вариант - мултиплексиране на I/O - създават се множества от сокети и има функции, които ги poll-ват и ако се появи събитие на някой сокет, може да се обслужи. Така, голям брой сокети могат да се обслужват само от един процес или нишка и това става доста бързо. Лошото в цялата работа обаче е че Apache не работи по този начин (за разлика промерно от postfix). Този метод си има недостатъци така или иначе, примерно една блокираща операция където и да е, ще блокира целия сървърен процес. Сега представи си, че имаш PHP скрипт, който викне да речем sleep() - целия сървър ще "заспи" и други заявки няма да се обслужват през това време

Та очевидно Apache трудно ще работи по този начин, освен ако не сервира само статично съдържание. Но при все това, разработчиците му не са го направили да работи по този начин.

[lkr]

Че кой има такива проблеми, специално за динамично съдържание, така или иначе повечето време ти отива I/O, а пък и вече всеки си има собствен сървър (tornado, mongrel, etc) ...

[gat3way]

Заявки в секунда != паралелнo обслужени заявки. Освен ако не са тежки заявките,  сървърът може да обслужи доста повече заявки в секунда, отколкото паралелни заявки.

Ето пример с httperf (взето оттук: http://modperlbook.org/html/9-1-2-httperf.html )

Код:

Total: connections 5000 requests 5000 replies 5000 test-duration 5.854 s

5000 заявки са изпратени към сървъра, на които е отговорено за 5.8 секунди.

Код:

Connection rate: 854.1 conn/s (1.2 ms/conn, <=50 concurrent connections)
Connection time [ms]: min 0.8 avg 23.5 max 226.9 median 20.5 stddev 13.7
Connection time [ms]: connect 4.0
Connection length [replies/conn]: 1.000

854 връзки се отварят средно в секунда към сървъра, но както казва httperf, паралелизмът е доста по-нисък, около или по-малко от 50 паралелни конекции.

Код:

Request rate: 854.1 req/s (1.2 ms/req)
Request size [B]: 79.0

Reply rate [replies/s]: min 855.6 avg 855.6 max 855.6 stddev 0.0 (1 samples)
Reply time [ms]: response 19.5 transfer 0.0
Reply size [B]: header 184.0 content 6.0 footer 2.0 (total 192.0)
Reply status: 1xx=0 2xx=5000 3xx=0 4xx=0 5xx=0

854-855 заявки и отговори на заявките в секунда. Request rate-a не е много интересен, защото зависи от мрежата и машината, на която върви httperf. Reply rate/time-a е важен - сървърът е успял да отговори на 855 заявки в секунда, но както се вижда, всяка заявка отнема около 20 милисекунди, за да се обслужи. Като умножим 855*20 => получаваме 17,100 милисекунди. Тоест, грубо казано, паралелизмът реално се е движил средно около 17 паралелни заявки, просто заявките се обслужват доста бързо.

Код:

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Да, и няма грешки. Тестът са го пуснали срещу perl скрипт, който предполагам не върши кой знае каква работа, иначе нямаше да отговаря толкова бързо (20мс на заявка). Всъщност, едва ли върши, защото reply size-a е само 6 байта

Та в общи линии, това е разликата между паралелни заявки и заявки/секунда. Звучат доста сходно, но са различни неща. Паралелните заявки са броя на заявките, които се обслужват в точно определен момент от времето. Заявките в секунда са тези обслужени в рамките на една секунда. Една секунда може да е много време ако заявките са леки

[lkr]

А да, то аз въобще не съм прочел, че става въпрос за паралелни заявки. Въпреки че пак не виждам смисъл, при положение, че нямаш state, да следиш за паралелни заявки 8>

[gat3way]

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


Иначе, ето една много интересна страничка по въпроса:

http://www.kegel.com/c10k.html

[backi]

Благодаря на всички, които писаха по темата - отговорите ви, са ми доста полезни.

Значи става въпрос за 5 000 - 10 000, логанти потребители, групирани в групи по интереси и вътре в групата ще има комуникация между членовете с видео, аудио и chat.

Грубо и много амбициозно казано, нещо като фейсбук, който позволява видеоразговори на потребителите си.

Възниква въпроса дали БГ Хостерите имат техническа възможност за подръжка/хостване на такъв сайт? Ако някой от вас има преки впечатления може да препоръча хостер.

Т.к. от коментарите по-горе става ясно, че производителността на Apache, е пряко зависима от хардуера, може да препоръчате и сериозен сървър.

Отворени сме към всякакви предложения...
Още сме на етап планиране.

[plamen_f]

Хм

ми те въпросите ще завалят един след друг...
Първият е - как аджеба ще тествате такова нещо в реални условия? Щом говориш за предложение за сървър - значи ще търсиш ко-локация?

имам още много, ама така практичски погледнато все ще се почне от някъде

[backi]

Единият варинат е да хостнем сайта при някой хостер.
Другият вариант е да си закупим сървър и да го сложим в някой дейтацентър.

За момента сме се насочили към първият вариант, защото 5000 - 10000 посетители трудно ще ги наберем веднага и това ни дава основание да се спрем към  някой от пакетите, които предлагат хостерите. Проблемът идва от там дали след като се увеличи трафика към сайта, хостерът ще може да поеме този трафик и при какви условия.

Ей сега ако има хостери тук, могат да направят предложенията си на следните мейли:

b.razmanov@icentres.net
backi@abv.bg