Лучший (или подходящий) сервер WSGI для этого скрипта Python?- питон - PullRequest
Новая
       44

Лучший (или подходящий) сервер WSGI для этого скрипта Python?- питон

0 голосов
/ 22 апреля 2010

У меня возникли проблемы с решением, как обслуживать несколько скриптов Python.

Проблема в том, что основные функции можно обобщить следующим образом: 

do_something()
time.sleep(3)
do_something()

Я пробовал различные WSGI-серверы , но все они давали мне ограничения по параллелизму, так как я должен указать, сколько потоков использовать, и так далее.

Я только хочу, чтобы ресурсы на сервере использовались эффективно и свободно.

Есть идеи?

Ответы [ 4 ]

1 голос
/ 22 апреля 2010

Вы проверяли торнадо с его неблокирующими асинхронными запросами?

http://www.tornadoweb.org/

Я никогда не использовал его, но вот пример из документа: 

class MainHandler(tornado.web.RequestHandler):
    @tornado.web.asynchronous
    def get(self):
        http = tornado.httpclient.AsyncHTTPClient()
        http.fetch("http://friendfeed-api.com/v2/feed/bret",
                   callback=self.async_callback(self.on_response))

    def on_response(self, response):
        if response.error: raise tornado.web.HTTPError(500)
        json = tornado.escape.json_decode(response.body)
        self.write("Fetched " + str(len(json["entries"])) + " entries "
                   "from the FriendFeed API")
        self.finish()
1 голос
/ 22 апреля 2010

Вы можете найти Нерест хорошей подгонки. Он имеет несколько вариантов развертывания, один из которых является несколько прозрачным асинхронным (как реализовано в Eventlet ). Так что, если вы буквально делаете time.sleep(3), все будет хорошо. Не все, что вы можете сделать, прозрачно обрабатывается, поэтому вы должны обратить внимание на Eventlet и на то, как он работает. Сокеты, например, так что если вы читаете из сокета (и блоков этого сокета), это не остановит сервер или не потребует поток. Но если вы выполняете нагрузку на процессор, это блокирует все запросы. Так что ... это немного сложно. В Spawning есть и другие варианты развертывания, которые тоже могут вам подойти.

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

0 голосов
/ 23 апреля 2010

Значит, нормально, чтобы клиент был связан, ожидая ответа в течение 3 секунд, но не в порядке для сервера? Это кажется ... странным.

Если вы предпочитаете , а не , чтобы клиент был связан в течение 3 секунд, общий механизм заключается в том, чтобы первоначальный запрос возвращал «202 принято» как можно скорее с URL-адресом монитора состояния. Затем сервер может создать новый поток или подпроцесс для задачи, а клиент может выполнить другие действия, а затем запросить URL-адрес состояния, чтобы узнать, когда задача выполнена.

0 голосов
/ 22 апреля 2010

А как насчет сервера CherryPy WSGI?

Что это значит sleep? Вы действительно пишете веб-приложение?

...