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

Question

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

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

Answer 1

Вишневый.Функции, перечисленные на веб-сайте:

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

Answer 2

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

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

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

Answer 3

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

twistd web --wsgi=your.wsgi.application

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Веб-сайт CherryPy находится http://cherrypy.org/

Answer 10

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

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

Я бы обобщил Пилоны следующим образом:

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

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

Удачи.

Answer 11

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

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