Защо уеб сървърите на Python са нестабилни?

Разработвам базирана на HTTP сървър игра в Python. Планът е да има възможно най-малко зависимости, така че исках да работи без инсталиране на самостоятелен уеб сървър (като Apache, Lighttpd или nginx). Проблемът е, че не работи.

Пробвах следните версии:

  • BaseHTTPServer.HTTPServer (+SocketServer.ThreadingMixIn)
  • wsgiref.simple_server
  • twisted.web.server

Когато са подложени на голямо натоварване (siege -b -c 100 -t 30s), всички те частично се провалиха и с двете

[error] socket: read error Connection reset by peer sock.c:460: Connection reset by peer

or

[error] socket: -1313092800 address is unavailable.: Cannot assign requested address

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

От друга страна, когато опитах Lighttpd + Flask (т.е. WSGI) или дори Lighttpd + PHP (само като контролен случай), работи абсолютно добре. Наличност 100%, паралелност 100%.

Поради последните работещи версии, предполагам, че проблемът не е siege, или изпълнение на siege и сървъра на една и съща машина, или самата машина (Ubuntu 12.04 между другото).

ЗАБЕЛЕЖКА: във всички случаи тествах прости сървъри "hello world", за да минимизирам възможността за грешки.

И така моите два въпроса:

  1. Защо уеб сървърите на Python са нестабилни? (Каква точно е причината, а не решението?)
  2. Използването на самостоятелен уеб сървър + Python единственото/най-доброто решение ли е (ако се придържам към Python), или пропускам нещо?

python sockets wsgi webserver
person Andras Nemeth    schedule 08.10.2013    source източник
comment
Предполагам, че гласуването против е, защото този въпрос е малко извън обхвата на stackoverflow - мисля, че ще пасне по-добре на ServerFault.   -  person Brionius    schedule 08.10.2013
comment
@Brionius Благодаря. Това има смисъл.   -  person Andras Nemeth    schedule 08.10.2013
comment
@Brionius Оказа се, че няма смисъл. Бях изпратен обратно тук с няколко отрицателни гласа... :-)   -  person Andras Nemeth    schedule 08.10.2013

Отговори (1)


arrow_upward
2
arrow_downward

И така, моите два въпроса: Защо уеб сървърите на Python са нестабилни? (Каква точно е причината, а не решението?)

Проблемът тук е думата нестабилен. Достигате лимита за внедряване на сървърния процес. Това не означава непременно, че е нестабилен. Все едно да тласкаш колата си до предела й. Когато няма повече скорост, която можете да наберете, бихте ли казали, че колата ви е нестабилна?

Това е типичен проблем за „намирането на добър инструмент за правилната работа“. Едно нещо е сървърът на приложения, а другото е обслужването на голямо количество заявки и обработката на групирането на връзки. Последното е задача, управлявана от (уеб) сървъри като nginx, lighttpd, apache, uwsgi, които са създадени да се справят с паралелността и маршрутизирането.

В детайли, сървърите, които опитахте, са създадени да обработват максимален брой заявки. След достигане на това ограничение те прекъсват връзките. Те не са създадени да поставят връзката на опашка за по-късно.

Ако никога не сте опитвали, разгледайте и Tornado, добър е за сървъри за игри.

Използването на самостоятелен уеб сървър + Python единственото/най-доброто решение ли е (ако се придържам към Python), или пропускам нещо?

да Това е най-доброто решение и не само за Python. Това е често срещан модел на проектиране. Ще видите същия подход дори в Ruby, PHP, Java.. Най-честата задача е да се разпредели натоварването в клъстер от сървъри за приложения.

Типична среда е:

USER -> BALANCER (nginx,apache,ecc) -> APPSERVER (uwsgi, twisted, gunicorn, ..) -> WSGI Application
person Paolo Casciello    schedule 08.10.2013
comment
Така че основно това, което липсва, е групирането на връзки? И теоретично може да се създаде скрипт на Python, който да се справи с това? (Не като най-доброто решение, просто за да разберете проблема по-добре.) - person Andras Nemeth; 08.10.2013
comment
Обединяването на Conn е по-голямо, отколкото изглежда. Има проблем с c10k en.wikipedia.org/wiki/C10k_problem И да, той може да бъде решен , както се каза погледнете Торнадо. След това има още други проблеми, като отпечатък на паметта, python GIL (така че ще започнете да обслужвате заявки по мултипроцесен начин)... - person Paolo Casciello; 08.10.2013