ФорумПрограммированиеPython → Выбор веб-сервера для многопоточного Python приложения

Выбор веб-сервера для многопоточного Python приложения

  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 16:16

    Всем привет.

    Ситуация следующая:
    Написал многопоточный парсер на питоне с использованием модуля multiprocessing.dummy. Добавил Django для разработки веб интерфейса приложения. На рабочей машине под джанговским веб-сервером все работает замечательно. При переносе на VPS решил сделать все "как надо" и поставил nginx + gunicorn. Потом уже понял, что получилось, как всегда. Принцип работы Gunicorn я до конца еще не понял, но под многопоточность он явно не подходит.

    Хотелось бы услышать совет, какой веб-сервер лучше поставить и какие фреймворки в будущем использовать под подобные задачи.

    Сейчас склоняюсь к тому, чтобы оставить родной джанговский веб-сервер. Работает и работает ))

    P.S. С Python знаком недавно.

  • phpdude

    Сообщения: 26618 Репутация: N Группа: в ухо

    Spritz 4 октября 2015 г. 16:30, спустя 13 минут 37 секунд

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

    Сапожник без сапог
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 16:49, спустя 19 минут 25 секунд

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

    @phpdude, Парсер по сути отдельное приложение. Джанга для удобства, чтоб юзать не через консоль парсер, а через веб UI.

  • phpdude

    Сообщения: 26618 Репутация: N Группа: в ухо

    Spritz 4 октября 2015 г. 16:55, спустя 5 минут 35 секунд

    @ArtemVortax, а как они между собой общаются тогда и как может быть связан тип запуска жанги? :) Что за ошибка у тебя возникает в принципе? что пишут сервера?

    Сапожник без сапог
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 17:14, спустя 19 минут 39 секунд

    @ArtemVortax, а как они между собой общаются тогда и как может быть связан тип запуска жанги? :) Что за ошибка у тебя возникает в принципе? что пишут сервера?

    @phpdude, Все работает через джангу. Она и запускает парсер, когда приходит определенный ajax запрос. В это время висит соединение, пока парсер работает, по окончании возвращается ответ клиенту.
    Кроме того, есть ajax polling, который стучится с определенной периодичностью на сервак, дабы узнать как дела у парсера.
    Так вот, на джанговском веб-сервере все работает как надо и на каждый "лонг-поллинг" сразу приходит ответ. А gunicorn "собирает" все эти запросы и через время, когда закончит работать парсер, всю пачку разом отдает.
    Кстати говоря, я из парсера в качестве отладки выдаю что нибудь принтом в консоль. Так вот, ситуация такая же как и с ajax'ом. В консоль все выдается только после окончания работы скриптов, а не асинхронно.

    Ошибок не видно, не могу найти.

  • phpdude

    Сообщения: 26618 Репутация: N Группа: в ухо

    Spritz 4 октября 2015 г. 17:29, спустя 14 минут 36 секунд

    А gunicorn "собирает" все эти запросы и через время, когда закончит работать парсер, всю пачку разом отдает.

    @ArtemVortax, а вот тут не совсем факт :)

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

    Это частая проблема в такого рода задачах. Какой драйвер сессий используешь ?

    Спустя 160 сек.

    это скажем так, первая штука которую я бы проверил :)

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

    Сапожник без сапог
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 17:37, спустя 7 минут 50 секунд

    Да, сессии используются, SessionStore. Сейчас тоже все нормально работает, но не gunicorn, а на джанговском сервачке.

  • phpdude

    Сообщения: 26618 Репутация: N Группа: в ухо

    Spritz 4 октября 2015 г. 17:42, спустя 5 минут 29 секунд

    @ArtemVortax, у тебя есть драйвер сессий, какой то, который указан в settings.SESSION_ENGINE

    Сапожник без сапог
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 17:43, спустя 49 секунд

    @ArtemVortax, у тебя есть драйвер сессий, какой то, который указан в settings.SESSION_ENGINE

    @phpdude, Нет

  • phpdude

    Сообщения: 26618 Репутация: N Группа: в ухо

    Spritz 4 октября 2015 г. 17:45, спустя 1 минуту 53 секунды

    выведи в консоль это и скажи какой драйвер юзается в случае обоих серверов. импортировать settings незабудь

    from django.conf import settings

    Сапожник без сапог
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 4 октября 2015 г. 18:05, спустя 20 минут 17 секунд

    django.contrib.sessions.backends.db
    В обоих случаях

  • Sinkler

    Сообщения: 9658 Репутация: N Группа: в ухо

    Spritz 5 октября 2015 г. 1:19, спустя 7 часов 13 минут 56 секунд

    @ArtemVortax, привет, сосед shipit

    Кстати говоря, я из парсера в качестве отладки выдаю что нибудь принтом в консоль. Так вот, ситуация такая же как и с ajax'ом. В консоль все выдается только после окончания работы скриптов, а не асинхронно.

    то есть если ты на том же серваке с теми же настройками запустишь это через nginx + runserver, то выдаваться в консоли будет сразу же?

    а вообще, как сказал дуд, блокировка скорее всего из-за кода, а не из-за сервера) какие процессы у тебя происходят при каждом запросе: что куда/откуда пишется/читается?

  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 5 октября 2015 г. 3:44, спустя 2 часа 24 минуты 59 секунд

    @ArtemVortax, привет, сосед shipit

    Кстати говоря, я из парсера в качестве отладки выдаю что нибудь принтом в консоль. Так вот, ситуация такая же как и с ajax'ом. В консоль все выдается только после окончания работы скриптов, а не асинхронно.

    то есть если ты на том же серваке с теми же настройками запустишь это через nginx + runserver, то выдаваться в консоли будет сразу же?

    а вообще, как сказал дуд, блокировка скорее всего из-за кода, а не из-за сервера) какие процессы у тебя происходят при каждом запросе: что куда/откуда пишется/читается?

    @Sinkler, привет-привет )). Согласен, дело скорее всего в коде, там используются блокировки. Сейчас попробую nginx + runserver

  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Джедаи

    Spritz 5 октября 2015 г. 3:52, спустя 7 минут 27 секунд

    nginx + runserver также замечательно работает

    Спустя 273 сек.

    По поводу логики работы приложения. Клиентом делается запрос на парсинг. В многопоточном режиме джанга через view запускает парсинг. В процессе работы идет запись в базу. Все это время висит одно соединение, по окончании работы клиенту отдается response. На соединеие я также наложил "Lock" модуля threading, чтобы парсер работал только в одном экземпляре.
    В это же время клиент стучится через ajax поллинг на сервер. За него отвечает другая вьюха. Она обращается к базе, чтобы узнать статистику. Узнает и сразу отдает клиенту.

  • Sinkler

    Сообщения: 9658 Репутация: N Группа: в ухо

    Spritz 5 октября 2015 г. 3:57, спустя 5 минут 35 секунд

    @ArtemVortax, я не использовал gunicorn, может ты перемудрил там с чем-нибудь в настройках?

    runserver использовать плохо на боевом сервере, можно попробовать uwsgi вместо gunicorn

Пожалуйста, авторизуйтесь, чтобы написать комментарий!