1. Comet-сервер
своими руками
Макс Лапшин
Дмитрий Демещук

2. Эволюция веба

3. Никакого real-time

4. Немного real-time

5. Сплошной real-time

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
• Один баг-опечатка

29. dps:subscribe("Channel").
dps:publish("Channel", “Message”).

30. Тесты
• Выявили race condition
• Очень помогли в дальнейшей разработке
• Отняли несколько часов
• Покрыли примерно 80% кода pub/sub-части
• По размеру сравнимы с кодом

31. Comet добавляется за час

32. Прикрутили чатик на JS.
Попутно оказалось, что
кроссдоменный long-poll
не работает в Safari.

33. Все круто,
все работает.

34. Спасибо за внимание

35. И тут пришли они

36. Попытка №0:
подозрительно
хорошие результаты

37. Мы просто слали сообщения
и измеряли rps.
(Redis проиграл
уже на этом этапе)

38. Вывод:
бенчмарки должны
соответствовать
продакшну

39. Попытка №1
• Amazon EC2 large instances
• 1000 клиентских подключений
• 1 rps с каждого клиента

40. На этот раз,
бенчмарк-процессы
работают приближенно
к живым клиентам

41. • 20-140% CPU на одной машине
• Репликация все убила

42. Структура на одной ноде

43. Репликация между нодами

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