Comet-сервер своими руками

Мой и Макса Лапшина доклад на Highload++ 2012.

Transcript

1. Comet-сервер своими руками Макс Лапшин Дмитрий Демещук
2. Эволюция веба
3. Никакого real-time
4. Немного real-time
5. Сплошной real-time
6. После загрузки, современная страница продолжает жить своей жизнью.
7. Данные поступают по инициативе сервера
8. Возможные реализации • Периодические запросы на сервер • Comet: • Long polling • Websockets • Server Sent Events • Прочее гуано (Flash sockets)
9. • Много запросов впустую • Постоянная загрузка • Задержки Периодические запросы
10. • Не требует немедленного ответа • Совместим с keepalive • Моментальное обновление • Много одновременных подключений • Требуется переподключение Long-polling
11. • Постоянное соединение • Намного быстрее, чем HTTP • Не везде поддерживаются • Еще не устоялись как стандарт
12. Выбор очевиден:* * часто в сочетании с таймером
13. • Ruby EventMachine • Python Twisted • Node.JS • Erlang
14. “Стойте, я же могу просто сделать это на чистом PHP!”
16. • CGI - ~1000-2000 • Apache - 1000-5000 • Node.JS - 1000000 (?) • Erlang - 2277845 Лимит одновременных подключений
18. Хранение внутреннего состояния • MySQL — надежно и очень медленно • Redis/memcached — ненадежно и медленно • Внутри VM — быстро и опасно • Репликация
19. Внутреннее состояние хочется реплицировать
20. Почти всегда нужна доставка сообщений
21. А еще, очень хочется failover
22. Нет решений для распределенного комета из коробки • Redis - master-slave репликация • Memcached - нет сообщений • Postgres - медленно и без репликации
23. RabbitMQ • Возможность хранения истории • Возможность использования вебсокетов • Нет long polling из коробки
24. Все приходится делать самим
25. Нельзя просто так взять и написать распределенный comet-сервер Нельзя просто так взять и написать распределенный comet-сервер
26. Почему Erlang • Феноменальная для веба производительность • Феноменальная для веба многоядерность • Распределенность из коробки • Асинхронный IO в последовательном виде • Изоляция данных • Горячее обновление кода
27. DPS - distributed pub/sub https://github.com/doubleyou/dps
28. Желаемые фичи • In-memory • История сообщений в канале • Горячий бэкап нод • Zero-conf, no-ops сервер
29. Хроника событий 1. Реализация pub/sub-механизма 2. Написание тестов 3. Прикручивание веб-сервера 4. Доработка напильником 5. Бенчмарки 6. ... 7. PROFIT!
30. • Распределенный • Автоматический failover • Написан за 2.5 часа • Меньше 300 строк кода • Один race condition • Один баг-опечатка Первый рабочий pub/sub
31. dps:subscribe("Channel"). dps:publish("Channel", “Message”).
32. Тесты • Выявили race condition • Очень помогли в дальнейшей разработке • Отняли несколько часов • Покрыли примерно 80% кода pub/sub-части • По размеру сравнимы с кодом
33. Comet добавляется за час http://levgem.livejournal.com/409755.html
34. Прикрутили чатик на JS. Попутно оказалось, что кроссдоменный long-poll не работает в Safari.
35. Все круто, все работает.
36. Спасибо за внимание!
37. И тут пришли они Бенчмарки
38. Попытка №0: подозрительно хорошие результаты
39. Мы просто слали сообщения 300 000 publishes per second
40. Вывод: бенчмарки должны соответствовать продакшну
41. Разные профили нагрузки • Whatsapp: 2M online, 12k pps • Ejabberd: 40k online, 40k pps
42. Попытка №1 • Amazon EC2 large instances • 1000 клиентских подключений • 1 rps с каждого клиента
43. На этот раз, бенчмарк-процессы работают приближенно к живым клиентам
44. • 20-140% CPU на одной машине • 2000 deliveries per second Мы посовещались и решили, что Amazon не очень
45. Структура на одной ноде
46. Репликация между нодами
47. • Асинхронная репликация • Messages discarding • Replication dropping Sacrificial degradation
48. Асинхронный publish на соседние ноды облегчил ситуацию, но не решил проблему.
49. 10 000 deliveries per second с асинхронной репликацией, работает
50. 20 000 deliveries per second - через некоторое время обсыпается с timeout
51. Интроспекция в Erlang как она есть
52. Все дело в очередях
53. Низкое время ответа может быть вредно
54. Long polling рассчитан на редкие ответы с сервера. У нас же он превратился в short-polling.
55. Выходы* • Таймаут на клиенте • Таймаут на сервере • Пользовательские сессии * лучше - в комбинации
56. Сессии - почти те же каналы
57. 7500 publishes per second 150 000 deliveries per second
58. 200 000 deliveries per second обсыпается с timeout
59. • Клиент шлет сообщение в полную очередь • Отваливается с таймаутом • Перепосылает в ещё более полную очередь • OOM Killer In Da House Замкнутый круг
60. Вывод: надо тщательно продумывать rate limit control
61. • Перед публикацией проверяем длину очередей • Если большая, шлем HTTP 429 • Клиент сам перепошлет завтра позже Power of Erlang
62. Итого
63. Сервер написан и протестирован за несколько человеко-дней
64. Неплохая производительность: WhatsApp - ~11500 pps DPS - ~7500 pps Функциональность и железо разные, но порядок цифр похожий.
65. Важные моменты • Не следует хранить всю историю в памяти • Следите, какие процессы перегружаются • Избегайте избыточных сообщений • Не делайте запросы слишком часто • Используйте пользовательские сессии • Старайтесь не гонять лишние данные
66. Erlang - не серебряная пуля, но позволяет фокусироваться на более высокоуровневых задачах
67. Тесты и бенчмарки с лихвой окупили себя.
68. Что дальше? • DHT Ring для распределения каналов • Персистентность • Регулировка consistency/availability
69. Технические компромиссы могут заметно ускорить работу сервера. • Не хранить очереди • Терять сообщения • Отказаться от сессий (в некоторых случаях) • Посылать все в /dev/null
70. Вопросы? Макс Лапшин max@maxidoors.ru Дмитрий Демещук demeshchuk@gmail.com