Почему веб-серверы Python нестабильны?

Я разрабатываю игру на основе HTTP-сервера в Python. План состоит в том, чтобы иметь как можно меньше зависимостей, поэтому я хотел, чтобы он работал без установки отдельного веб-сервера (например, Apache, Lighttpd или nginx). Проблема в том, что это не работает.

Пробовал следующие версии:

  • BaseHTTPServer.HTTPServer (+SocketServer.ThreadingMixIn)
  • wsgiref.simple_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) или я что-то упускаю?

person Andras Nemeth    schedule 08.10.2013    source источник
comment
Я предполагаю, что отрицательный голос связан с тем, что этот вопрос немного выходит за рамки stackoverflow - я думаю, что он лучше подходит для ServerFault.   -  person Brionius    schedule 08.10.2013
comment
@Бриониус Спасибо. В этом есть смысл.   -  person Andras Nemeth    schedule 08.10.2013
comment
@Brionius Оказалось, это не имеет смысла. Меня отправили обратно здесь с несколькими минусами... :-)   -  person Andras Nemeth    schedule 08.10.2013


Ответы (1)


Итак, два моих вопроса: почему веб-серверы 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 pooling больше, чем кажется. Есть проблема c10k en.wikipedia.org/wiki/C10k_problem И да, с ней можно справиться , как сказано взгляните на Торнадо. Тогда есть еще другие проблемы, такие как объем памяти, GIL python (так что вы начнете обслуживать запросы многопроцессорным способом)... - person Paolo Casciello; 08.10.2013