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

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

  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Адекваты

    Spritz 7 октября 2015 г. 16:00, спустя 1 час 11 минут 14 секунд

    @ArtemVortax, да, конечно. Я просто давным-давно не видел сервера с одним ядром))

    Тогда просто парси больше страниц.

    Запускать несколько процессов на одном ядре смысла не имеет. И не важно как ты это будешь делать - руками, supervisord, cluster и т.п. Общий рантайм процесса прожорливый, а ты его множишь (и пофиг что в основе - loop, multithread и т.п.). Можешь запустить один процесс с 100 страниц в единицу времени и запустить 10 процессов по 10 страниц и посмотреть загрузку.

    @mathete, сервачок тестовый за 4 бакса ))

    В том то и проблема, что я не могу одним процессам парсить по-максимуму, поэтому я и размножил его. Не понимаю, что именно ограничивает приложение.

  • adw0rd

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

    Spritz 7 октября 2015 г. 16:24, спустя 23 минуты 14 секунд

    В этом плане GIL и треды питона оправдывают себя, т.к. под парсингом подразумевается обычно краулинг, а это не просто разбор данных, а запросы по сети и сохранения данных на диск, зато процессорное время одно
    Получается с виду для CPU это один процесс, для диска и сети их много, люблю треды питона

    Спустя 29 сек.

    Я не против ноды и эрланга, если что. Просто офтоплю, пока автор играется со своим проектом

    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • mathete

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

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

    @ArtemVortax, не можешь это как? Что-то инициирует нагрузку. Увеличь это значение. Всегда есть параметры интенсификации.

    @adw0rd, ты прикидывал насколько на тредах накладнее, чем на асинхронности? Та пропость, которую я видел между тредами с одной стороны и tornado.httpclient, или gevent с другой заставили меня забыть о тредах. Обычно, пока создаётся тред и GIL чего-то там шуршить, в асинхронном приложении уже всё заканчивается. Классический пример противостояния на низкоуровневом коде - apache vs nginx. Если apache добавить GIL, то будет ещё смешнее:)

    Я вот смотрю на saghul/pyuv [github.com] и думаю. Задумка хорошая, но из-за GIL толком выжать ничего не получится... Я имею в виду тредовые вещи.

  • adw0rd

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

    Spritz 7 октября 2015 г. 17:15, спустя 1 минуту 57 секунд

    ты прикидывал насколько на тредах накладнее, чем на асинхронности?

    не прикидывал, мне бы ссылочку на бенчмарки
    понятно что быстрее будет, но хочется увидеть пропость

    Спустя 28 сек.

    @mathete, спасибо за pyuv, гляну

    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Адекваты

    Spritz 7 октября 2015 г. 18:39, спустя 1 час 23 минуты 36 секунд

    @ArtemVortax, не можешь это как? Что-то инициирует нагрузку. Увеличь это значение. Всегда есть параметры интенсификации.

    @mathete, Чем больше я даю нагрузку на async, тем медленнее работает приложение при той же нагрузке на проц и все остальное

  • mathete

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

    Spritz 7 октября 2015 г. 20:25, спустя 1 час 45 минут 40 секунд

    @ArtemVortax, ну не видя код, толком сказать нельзя.

    Навскидку:

    1. Либо у тебя, или в библиотеках, что ты юзаешь, где-то закралась синхронная работа. Один fs.readFileSync, может помножить на ноль все старания:)

    2. Как уже выше предпологал, @Crank, ты упираешься в io. Только не обязательно сеть, может диск. Посмотри общий la, при работе, параметр wa в top, открытые дескрипторы, нагрузку на канал и т.п. Но это наврядли, если запуск дополнительных процессов пропорционально поднимает продуктивность.

    3. Где-то юзается корявый c++ модуль. Но это ещё более наврядли - ты же не ставил, или сам не писал непонятный аддон.

    P.S. Ты используешь какой-то async. Я не знаю, что это такое, пошёл посмотрел, так и не понял, для чего он... Попробуй без него.

  • ArtemVortax

    Сообщения: 48 Репутация: N Группа: Адекваты

    Spritz 8 октября 2015 г. 23:51, спустя 1 день 3 часа 26 минут

    @ArtemVortax, ну не видя код, толком сказать нельзя.

    Навскидку:

    1. Либо у тебя, или в библиотеках, что ты юзаешь, где-то закралась синхронная работа. Один fs.readFileSync, может помножить на ноль все старания:)

    2. Как уже выше предпологал, @Crank, ты упираешься в io. Только не обязательно сеть, может диск. Посмотри общий la, при работе, параметр wa в top, открытые дескрипторы, нагрузку на канал и т.п. Но это наврядли, если запуск дополнительных процессов пропорционально поднимает продуктивность.

    3. Где-то юзается корявый c++ модуль. Но это ещё более наврядли - ты же не ставил, или сам не писал непонятный аддон.

    P.S. Ты используешь какой-то async. Я не знаю, что это такое, пошёл посмотрел, так и не понял, для чего он... Попробуй без него.

    @mathete, проблему решил, ошибка была где-то в коде. Теперь все из одного приложения работает.
    Async я использую в качестве менеджера асинхронных "потоков". У него есть удобные функции типа waterfall и mapLimit.
    Если бы я использовал просто модуль request, то мне пришлось бы считать все запросы, чтобы по окончании работы "потока", открывать следующий.
    Дело в том, что я сначала запускаю на парсинг один пакет урл, затем после него - второй. async.Waterfall прекрасно справляется с этой задачей.
    mapLimit асинхронно запускает парсинг и позволяет ограничивать количество одновременно запущенных соединений, плюс упорядочивает ответы в том порядке, в каком их запускал.

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