Практическая реализация распределенного отказоустойчивого Comet сервера на Erlang (Максим Лапшин, Дмитрий Демещук)
2 likes1,473 views
Документ представляет собой технический обзор о создании comet-сервера с использованием различных технологий, таких как long polling, websockets и server sent events. Обсуждаются проблемы и решения, связанные с эффективностью работы серверов, особенно в контексте распределенных систем и обработки сообщений. Автор делится опытом разработки и тестирования сервера, подчеркивая важность оптимизации производительности и хранения данных.
Практическая реализация распределенного отказоустойчивого Comet сервера на Erlang (Максим Лапшин, Дмитрий Демещук)
- 1. Comet-сервер своими руками Макс Лапшин Дмитрий Демещук
- 6. После загрузки, современная страница продолжает жить своей жизнью.
- 7. Возможные варианты • Периодические запросы на сервер • Comet: • Long polling • Websockets • Server Sent Events
- 8. Периодические запросы • Много запросов впустую • Постоянная загрузка • Задержки
- 9. Long-polling • Не требует немедленного ответа • Совместим с keepalive • Моментальное обновление • Много одновременных подключений • Требуется переподключение
- 10. • Постоянное соединение • Намного быстрее, чем HTTP • Не везде поддерживаются • Еще не устоялись как стандарт
- 11. Выбор очевиден:* * часто в сочетании с таймером
- 12. • Ruby EventMachine • Python Twisted • Node.JS • Erlang
- 13. “Стойте, я же могу просто сделать это на чистом PHP!”
- 15. Лимит одновременных подключений • CGI - ~1000-2000 • Apache - 1000-5000 • Node.JS - 1000000 (?) • Erlang - 2277845
- 17. Хранение внутреннего состояния • MySQL — надежно и очень медленно • Redis/memcached — ненадежно и медленно • Внутри VM — быстро и опасно • Репликация
- 18. Внутреннее состояние хочется реплицировать
- 19. Почти всегда нужна доставка сообщений
- 20. А еще, очень хочется failover
- 21. Нет решений для распределенного комета из коробки • Redis - master-slave репликация • RabbitMQ - нет истории • Memcached - нет сообщений
- 22. Все приходится делать самим
- 23. Нельзя просто так взять и написать распределенный comet-сервер
- 24. Почему Erlang • Феноменальная для веба производительность • Феноменальная для веба многоядерность • Распределенность из коробки • Отказоустойчивость • Изоляция данных
- 25. DPS - distributed pub/sub https://github.com/doubleyou/dps
- 26. Основные проблемы Разные профили нагрузки: есть большие каналы и много маленьких. Лаг между HTTP-ответом и коннектом к комету: нужна история. Нет времени на сохранение в SQL БД.
- 27. Хроника событий 1. Реализация pub/sub-механизма 2. Написание тестов 3. Прикручивание веб-сервера 4. Доработка напильником 5. Бенчмарки 6. ... 7. PROFIT!
- 28. Первый рабочий pub/sub • Распределенный • Автоматический failover • Написан за 2.5 часа • Меньше 300 строк кода • Один race condition • Один баг-опечатка
- 30. Тесты • Выявили race condition • Очень помогли в дальнейшей разработке • Отняли несколько часов • Покрыли примерно 80% кода pub/sub-части • По размеру сравнимы с кодом
- 31. Comet добавляется за час
- 32. Прикрутили чатик на JS. Попутно оказалось, что кроссдоменный long-poll не работает в Safari.
- 35. И тут пришли они
- 36. Попытка №0: подозрительно хорошие результаты
- 37. Мы просто слали сообщения и измеряли rps. (Redis проиграл уже на этом этапе)
- 38. Вывод: бенчмарки должны соответствовать продакшну
- 39. Попытка №1 • Amazon EC2 large instances • 1000 клиентских подключений • 1 rps с каждого клиента
- 40. На этот раз, бенчмарк-процессы работают приближенно к живым клиентам
- 41. • 20-140% CPU на одной машине • Репликация все убила
- 42. Структура на одной ноде
- 44. Асинхронный publish на соседние ноды облегчил ситуацию, но не решил проблему.
- 45. Все дело в очередях
- 46. Низкое время ответа может быть вредно
- 47. Выходы* • Таймаут на клиенте • Таймаут на сервере • Пользовательские сессии * лучше - в комбинации
- 48. Сессии - почти те же каналы
- 49. Производительность • В памяти хранить минимум истории • Полную историю хранить на диске, если нужно • Гарантированное время ответа
- 50. Long polling рассчитан на редкие ответы с сервера.
- 51. Как правило, лучше отправить один большой HTTP-ответ, чем много маленьких.
- 52. Попытка №2: сервер тянет 2000 rps, хоть и с трудом.
- 53. Перевели каналы целиком на ETS.
- 54. Попытка №3: 4000 rps!
- 55. Итого
- 56. Сервер написан и протестирован за несколько человеко-дней
- 57. Неплохая производительность: WhatsApp - ~11500 rps DPS - ~4000 rps Функциональность и железо разные, но порядок цифр похожий.
- 58. Важные моменты • Не следует хранить всю историю в памяти • Следите, какие процессы перегружаются • Избегайте избыточных сообщений • Не делайте запросы слишком часто • Используйте пользовательские сессии • Старайтесь не гонять лишние данные
- 59. Erlang - не серебряная пуля, но позволяет фокусироваться на более высокоуровневых задачах
- 60. Технические компромиссы могут заметно ускорить работу сервера.
- 61. Тесты и бенчмарки с лихвой окупили себя.
- 62. Вопросы? Дмитрий Демещук Макс Лапшин demeshchuk@gmail.com max@maxidoors.ru