Макс Лапшин - "EventMachine и evented архитектура"
Download as PPT, PDF1 like2,100 views
Документ описывает различные подходы к обработке запросов в серверных приложениях на Ruby, включая использование fork и нитей. Он подчеркивает проблемы с производительностью, связанными с многопоточностью и синхронизацией, а также преимущества использования библиотеки EventMachine для обработки асинхронных запросов. Также рассматривается возможность использования Fiber для оптимизации работы с многопоточностью и необходимость адаптации архитектуры под многоядерные системы.
Макс Лапшин - "EventMachine и evented архитектура"
- 2. fork per request Отстрел форка на запрос
- 3. Раньше была практика форкаться на запрос; copy-on-write позволял шарить между процессами код; невообразимо медленно, но для модемов нормально.
- 5. Apache первой версии, все воркеры держат accept; N-воркеров — N одновременных запросов; mod_php в безопасности; отдача файликов на модемы кладет сервер; дорогая межсерверная коммуникация.
- 6. Вместо процессов нитки thread pool
- 7. Для разделения данных между воркерами, запускаются треды. Те же процессы, но в одном адресном пространстве; Проблемы с синхронизацией ниток.
- 8. новые проблемы Много клиентов
- 9. При большом количестве одновременных запросов начинаются проблемы с шедулингом и переключением контекста; время поровну делится на клиентов и пропорционально количеству клиентов замедляется отдача ответа
- 10. Нитки отчасти помогают уменьшить стоимость переключения контекста, т.к. не требуют смены адресного пространства
- 11. Valgrind и gdb будут сниться ночью. Проезд по памяти осуществляется под нагрузкой и очень плохо отслеживается
- 12. Помимо непредсказуемости переключения, нитки неоптимальны по количеству переключений: Переключения в данном примере стоило бы делать так:
- 13. Нитки в Ruby Медленные; Не утилизируют ядра процессора; Реализованы самым неоптимальным способом; Основные библиотеки не threadsafe (мало кто вкладывает в это силы).
- 14. Evented Многие сетевые приложения делают частый ввод-вывод и быструю обработку данных (шаблонизация + проверки); Операции ввода вывода долгие и с неизвестным временем работы. Чем их ждать, лучше заниматься делом; Беда с дисковым вводом-выводом: он на текущий момент на практике синхронный; НЕ конечный автомат (FSM); Нитки в руби реализованы через вызов select.
- 15. Приходящее событие; Обработка; Запись данных в сокет.
- 16. EVentmachine Стандарт де-факто для Ruby 1.8; Ввод данных; Готовность к выводу данных; Таймер; Сигнал от OS (мертвый ребенок, SIGHUP и т.п.).
- 17. next tick Вместо delayed_job можно выполнить долгую операцию после текущего такта работы (на следующем run loop)
- 18. Проблемы Очень тяжело распиливать линейный код на колбеки; Использование многоядерности (evented приложения вообще стараются делать однонитевыми).
- 19. Fibers В Ruby 1.9 есть fibers — управляемые пользователем нитки. Coroutines; Команда Neverblock портировала их на Ruby 1.8; Revactor использует не Eventmachine, а стандарную libev; Совмещают удобства ниток и eventmachine.
- 20. multicore Руби пока далек от использования многоядерности; В 1.9 всё равно есть GIL; Возможно альтернативные команды помогут (Rubinius, MacRuby); Python тоже использует GIL; В Java нитки дорогие (системные, а не зеленые); Запускаем процессы по количеству ядер.
- 21. Выводы Fork очень дорогой; Не-evented архитектура плохо обслуживает много медленных клиентов; EventMachine для руби подходит прекрасно, огромное количество библиотек, всё хорошо; Fibers удобнее чем EventMachine, но мало используются; Для работы на многих ядрах запускается N рабочих процессов.