О Twisted Framework (доклад с HighLoad++-2009)

    В качестве введения в асинхронное программирование и самого поверхностного рассказа о Twisted Framework публикую материалы моего доклада на HighLoad++ (2009).

    Последнее время в области web происходит смещение внимания от «тяжелых» application-серверов, которые тратят на обработку запроса сотни миллисекунд, а то и секунды, к более легковесным сервисам, передающим меньшие объемы данных с минимальной задержкой. Переход от генерации десятков и сотен килобайт HTML-кода в ответ на запрос к передаче изменений в данных, запакованных в JSON и измеряемых сотнями байт. В качестве примеров таких сервисов можно привести Gmail, FriendFeed, Twitter Live Search и т.п.

    Для обеспечения минимальной задержки для пользователя необходимо либо поддерживать постоянное соединение (например, Adobe Flash, RTMP) или использовать технику HTTP long polling в сочетании с keep alive. Так или иначе на стороне сервера это приводит к появлению большого количества одновременных соединений (тысячи, десятки тысяч), по каждому из которых передается не такой большой объем данных. Эту ситуацию называют проблемой C10k.

    Для обработки соединений архитектурный выбор на стороне сервера не такой большой: процесс на соединение, нить на соединение, комбинированный вариант процесс-нити или асинхронный ввод-вывод (возможно, в сочетании с дополнительными процессами или нитями). При наличии более 10 тысяч одновременных соединений с точки зрения расхода ресурсов совершенно невозможно представить создание 10 тысяч процессов; 10 тысяч нитей также вряд ли будет разумным решением. Необходимо дополнительно учесть, что при наличии такого большого числа соединений объем работы по каждому из них относительно невелик, большинство их них простаивают в ожидании поступления новых данных. Поэтому бóльшая часть процессов или нитей будет просто находиться в состоянии ожидания, расходуя впустую системные ресурсы.

    Асинхронный ввод-вывод позволяет осуществлять неблокирующийся сетевой ввод-вывод по тысячам открытых сокетов в рамках одной нити выполнения (одного процесса). Механизмы реализации в разных ОС разные, например: select(), poll(), epoll(), kqueue() и т.п. Примеры приложений, использующих асинхронный ввод-вывод:
    • nginx (используются дополнительные процессы для обслуживания задач, требующих большего объема CPU);
    • haproxy;
    • memcached;
    • и другие.

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

    Twisted Framework — это обширный набор классов и модулей для реализации асинхронных сетевых приложений. Twisted Framework — это:
    • ядро, абстрагирующее все операции асинхронного ввода-вывода и использующее соответствующий механизм конкретной ОС;
    • концепция Deferred, которая позволяет реализовать в простой форме обслуживание запроса: асинхронные сетевые обращения (например, к БД, memcached), обработку ошибочных ситуаций; Deferred является аналогом обычных конструкций последовательного программирования для асинхронной модели программирования;
    • обширный набор уже реализованных сетевых протоколов: HTTP, DNS, SMTP, IMAP, memcached, Jabber, ICQ и т.д.; еще большее количество протоколов доступно в виде дополнительных модулей;
    • дополнительная инфраструктура: unit-testы с поддержкой Deferred, пулы нитей, процессов и т.д.;
    • качественная концепция разработки — полное покрытие unit-testами, строгий review любого изменения.

    В докладе в качестве конкретного примера приводятся три приложения, реализованные на Twisted с моим участием. Рассматривается архитектура, конкретные параметраы производительности, приемы оптимизации, преимущества и недостатками Twisted для решения данной задачи:
    • RTMP-сервер pyFMS, сервер вещаний сервиса Smotri.Com (сотни трансляций, десятки тысяч зрителей);
    • backend-сервер проекта MDC – хранение и обработка истории общения пользователей, хранение настроек и т.п.;
    • Qik Push Engine – сервер немедленной доставки изменений информации о видео, созданных пользователями сервиса, в том числе push-нотификация о появившихся live-стримах, масштабирование, обработка больших объемов информации.

    Дополнительная информация:

    Презентация


    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 24

      +1
      Спасибо.
        +1
        Не за что! Видео с конференции я, к сожалению, не могу найти.
        • НЛО прилетело и опубликовало эту надпись здесь
        0
        Спасибо за доклад на хайлоаде, мне очень понравился :)
          0
          Twisted хорош. Tornado еще лучше. Node.js самый лучший, ну и что, что не на питоне :)
            +1
            Чем Tornado то лучше? Я вот на него посмотрел, и понял что они пролетели — они облегчили Twisted на Deferreds, а это ошибка.
              –1
              Тем, что он проще, в нем нету кучи лишних вещей, редко нужных.
              И тем, что на нем работает френдфид → можно доверять :)
                +1
                Это которые вещи лишние? Deferreds? Ну-ка ну-ка, мне даже интересно — обоснуйте их ненужность.
                  –2
                  Это то, что там для управления callback'ами?
                  В Tornado проще, не надо ничем управлять, просто параметр callback=_my_callback где надо и декоратор @tornado.web.asynchronous перед всем безобразием :)
                    0
                    Проще, согласен, и потому убого. Расскажите мне, как вы передадите исключение таким способом?
                    Что есть в Tornado для запуска процессов?
                    Что есть в Tornado для управления пулами потоков?
                    Какие библиотеки есть для Tornado?
                  +1
                  Дело было примерно так — автор Tornado пытался понять Twisted, писал в список рассылки, спрашивал. Но так и не понял и сделал Tornado. Видимо, такова его ниша (Tornado) и такое «упрощенное» решение имеет право на существование.

                  Без обид. Просто другой взгляд на вещи.

                  Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.
                    –1
                    К сожалению, это не так. Писали FriendFeed на низком уровне, на чистом питоне. Потом из него вытащили Tornado.
                    Так же, как из Basecamp вытащили Rails.
                      0
                      Батенька трололо в общем. Низкоуровневый питон это уже за гранью.
                        0
                        /s/на низком уровне/без фреймворка/
                          0
                          Ладно, примем. Автор не осилил Twisted, deferreds, и написал свой велик, который и вполовину не дотягивает до оригинала.
                          Давайте Вы освоите Twisted, а потом обсудим?
                            –2
                            Зачем мне Twisted? Зачем мне что-то обсуждать?
                            Я высказал свое мнение: Tornado проще, а значит лучше.
                              +1
                              Я люблю, когда люди, высказывая свое мнение, приводят хорошие аргументы. Считаю себя в праве забивать на необоснованное ИМХО, да еще от не владеющих предметом.
                                0
                                Так забей — зачем отвечаешь?
                                Хороший аргумент — простота.
                                  0
                                  Я забиваю на ИМХО, а не на эффект от от его горделивого изложения.

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

                                  А также авторам node и Tornado, тоже очень бы пригодилось поучиться писать асинхронные фреймворки.

                                  P.S. не надо тыкать, уважайте собеседника.
                0
                Node.js может справится с подобными задачами? У него уже есть готовые решения, всмысле поддерживаемые протоколы и бэкэнды (больше всего интересует мемкешди)? Про асинхронность помню уже писали и ее вроде хвалили. Спасибо.
              0
              Подскажите, пожалуйста, в презентации еще упоминаются руби EventMachine. Насколько он хорош? Мне не важен язык, важна производительность фреймворка. Спасибо.
                +1
                Я не готов сравнить их. EventMachine — это «Twised на Ruby».

                То есть на верхнем уровне это скорее различие языков и философий программирования, определяемых языком.

                Вообще говоря Ruby MRI на сегодня медленнее Python.

                Может, кто из пробовавших оба расскажет?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое