Хороший многопоточный веб-сервер python?

Question

Я ищу веб-сервер python, который является многопоточным, а не мультипроцессом (как в случае mod_python для apache). Я хочу, чтобы он был многопоточным, потому что я хочу иметь кеш объектов памяти, который будет использоваться различными потоками HTTP. Мой веб-сервер делает много дорогостоящего материала и вычисляет некоторые большие массивы, которые необходимо кэшировать в памяти для использования в будущем, чтобы избежать перекомпоновки. Это невозможно в многопроцессорной среде веб-сервера. Хранение этой информации в memcache также не является хорошей идеей, поскольку массивы большие, и их хранение в memcache приведет к десериализации данных, поступающих из memcache, помимо дополнительных накладных расходов IPC.

Я реализовал простой веб-сервер с использованием BaseHttpServer, он дает хорошую производительность, но он застревает через несколько часов. Мне нужен еще более зрелый веб-сервер. Возможно ли настроить apache для использования mod_python в рамках модели потока, чтобы я мог выполнять некоторое кэширование объектов?

Answer 1

CherryPy. Особенности, перечисленные на веб-сайте:

• Быстрый, HTTP/1.1-совместимый WSGI-потоковый веб-сервер. Как правило, сам CherryPy занимает всего 1-2 мс на страницу!
• Поддержка любого другого WSGI с поддержкой веб-сервера или адаптера, включая Apache, IIS, Lighttpd, mod_python, FastCGI, SCGI и mod_wsgi
• Простота запуска нескольких серверов HTTP (например, на нескольких портах) сразу
• A мощная система конфигурации для разработчиков и так
за развертывание
• гибкой системы плагин
• Встроенных инструментов для кэширования, кодирование, сессий, авторизации статического контента, и многие адаптеры более
• уроженец mod_python
• полный комплект тестов
• Сменные и настраиваемые ... все.
• Встроенное профилирование, покрытие и поддержка тестирования.

Answer 2

Не многопоточно, но twisted может удовлетворить ваши потребности.

Answer 3

Возможно, у вас возникла проблема с реализацией в Python с использованием BaseHttpServer. Нет причин для «застревания», и внедрение простого поточного сервера с использованием BaseHttpServer и threading не должно быть затруднительным.

Также см http://pymotw.com/2/BaseHTTPServer/index.html#module-BaseHTTPServer о реализации простой многопоточный сервер с HTTPServer и ThreadingMixIn

Answer 4

Я использую CherryPy как лично, так и профессионально, и я очень счастлива с ним. Я даже делаю то, что вы описываете, например, глобальные кэши объектов, запуск других потоков в фоновом режиме и т. Д. И он хорошо интегрируется с Apache; просто запустите CherryPy как автономный сервер, привязанный к localhost, а затем используйте Apache mod_proxy и mod_rewrite, чтобы Apache прозрачно перенаправлял ваши запросы на CherryPy.

Веб-сайт CherryPy является http://cherrypy.org/

Answer 5

Вы могли бы вместо того, чтобы использовать распределенный кэш, который доступен из каждого процесса, memcached является примером того, что приходит на ум.

Answer 6

Рассмотрите возможность пересмотра вашего дизайна. Поддержание такого состояния на вашем веб-сервере, вероятно, является плохим. Многопроцессор - это гораздо лучший способ добиться стабильности.

Есть ли другой способ разделить состояние между отдельными процессами? Как насчет услуги? База данных? Индекс?

Похоже, что сохранение огромного массива данных в памяти и использование одного многопоточного процесса для обслуживания всех ваших запросов - это лучший дизайн или архитектура для вашего приложения.

Answer 7

Просто указать на что-то отличное от обычных подозреваемых ...

Несколько лет назад, когда я использовал Zope 2.x я прочитал о Medusa, как это было веб-сервер, используемый для платформы. Они рекламировали его, чтобы он работал хорошо при большой нагрузке, и он может предоставить вам необходимую вам функциональность.

Answer 8

Его трудно дать окончательный ответ, не зная, на каком участке вы работаете, и какую нагрузку вы ожидаете. Второе представление может быть серьезным требованием, или оно может и не быть. Если вам действительно нужно сохранить эту последнюю миллисекунду, вам абсолютно необходимо сохранить свои массивы в памяти. Однако, как утверждают другие, более чем вероятно, что вы не можете и могли бы получить что-то еще. Ваш шаблон использования данных в массиве может повлиять на ваши варианты выбора. Вероятно, вам не нужен доступ ко всему набору данных из массива сразу, чтобы вы могли разбить свои данные на более мелкие куски и поместить эти куски в кеш, а не один большой кусок. В зависимости от того, как часто ваши данные массива должны обновляться, вы можете сделать выбор между memcached, локальным db (berkley, sqlite, маленькой установкой mysql и т. Д.) Или удаленным db. Я бы сказал, memcached для довольно частых обновлений. Локальный db для чего-то на частоте часового и дистанционного для частоты ежедневно. Следует учитывать и то, что происходит после промаха в кеше. Если 50 клиентов вдруг получат пропуски в кеше, и все они в то же время решают начать регенерировать эти дорогостоящие массивы, ваш ящик (ы) будет быстро уменьшен до 8086. Поэтому вы должны принять во внимание, как вы справитесь с этим. В многочисленных статьях рассказывается о том, как восстановить недостатки кэша. Надеюсь, это полезно.

Answer 9

Twisted может служить в качестве такого веб-сервера. Хотя он и не является многопоточным, в текущем соединителе присутствует (еще не выпущенный) многопоточный контейнер WSGI. Вы можете проверить репозиторий SVN, а затем запустить:

twistd web --wsgi=your.wsgi.application 

Answer 10

У меня на самом деле была такая же проблема в последнее время. А именно: мы написали простой сервер с использованием BaseHTTPServer и обнаружили, что тот факт, что он не многопоточный, был большим недостатком.

Моим решением было отправить сервер на Pylons (http://pylonshq.com/). Порт был довольно прост, и одним из преимуществ было очень легко создать графический интерфейс с использованием Pylons, поэтому я смог отобразить страницу состояния поверх всего процесса демона.

Я хотел бы резюмировать пилоны таким образом:

• это похоже на Ruby On Rails, что он стремится быть очень легко для развертывания веб-приложений
• это по умолчанию язык шаблонный, Мако, очень приятно работать с
• использует систему маршрутизации URL-адресов, что очень удобно
• для нас производительность не является проблемой, так что я не могу гарантировать, что пилоны будет работать должным образом для ваших нужд
• вы можете используйте его с Apache & Lighthttpd, хотя я этого не пробовал

Мы также запускаем приложение с Twisted и довольны его. Twisted имеет хорошую производительность, но я считаю, что модель программирования Twisted с однопоточным/отложенным потоком довольно сложна. У этого есть много преимуществ, но не было бы моего выбора для простого приложения.

Удачи.

Answer 11

web.py сделал меня счастливым в прошлом. Подумайте об этом.

Но это звучит как архитектурный редизайн, который может быть правильным, хотя и более дорогостоящим решением.