Ну не думаю, что они долго в таком режиме проработали в бою:) Не секрет, что в ранних версиях Go массово аллоцирующим приложениям приходилось тяжко — приходилось переиспользовать все, что только можно, не использовать слайсы и указатели — заменять их массивами и копированием, чтобы не вызывать лишних аллокаций в куче. В прошлом году, когда по большому счету только начинал знакомство с Go, я попал на доклад «Go в Badoo» на московском митапе – отличный доклад и яркий пример борьбы с паузами GC в продакшене.
Our new transaction oriented collector or TOC algorithm focuses attention on these objects thus improving overall GC throughput and scalability while delaying the need to do a full heap GC.
Но, честно говоря, я сам в этот документ пока не вникал – знал только о его недавнем появлении:)
в 1.7 не нужно, вот тут как раз автор статьи зарепортил о своей проблеме с NUMA-доступом – часть работы, влияющей на длительность STW, перенесли в параллельную(конкуррентную) фазу и я так понял даже mbind в итоге не потребовался, чтобы значительно уменьшить длительность паузы.
Так как часть статьи посвящена конфигурации, от себя еще добавлю ссылку на статью Дейва Чейни. Смысл ее в том, что параметры конфигурации можно делать функциями, чтобы позволить пользователю библиотеки самому решать, какое поведение ему нужно в той или иной ситуации. Вот, например, использование этого подхода, в redigo, а вот пример из модуля net/http стандартной библиотеки.
Я думаю, что в случае Центрифуги ничего особо не держит, просто привычка дожидаться минорных версий с фиксами проблем, обнаруженных в релизе. Вообще, я думал к публикации статьи уже будет 1.6.1, но уже на 19 дней milestone 1.6.1 просрочен. Еще с 1.6 были проблемы у sockjs-go — если бы поспешил, то пропустил бы это в релиз.
pavel_d после комментария от igordata и небольшого обсуждения в ЛС судя по всему SharedWorker – вполне себе путь работать через одно вебсокет-соединение. Всю работу с Центрифугой можно возложить на воркер, который будет рассылать полученные сообщения табам. Но тут мне самому предстоит покопаться прежде чем что-то дополнительно смогу сказать.
Спасибо! Видимо я вам в ЛС напишу, чтобы получше разобраться с shared worker'ами – так с ходу и сказать нечего, потому что не сталкивался до этого и не до конца пока понимаю.
Пуш в Service Workers планируем, да — но только когда примут общий драфт для браузеров, чтобы не завязываться только на Хром и GCM, вот issue уже стоит. Но когда примут драфт пока не ясно.
Про unix socket: в Go функция ListenAndServe, которая запускает HTTP-сервер, слушает tcp адрес, поэтому я не могу утверждать, что если логику этой функции вынести в проект и использовать unix-сокет все будет корректно работать.
Не совсем так — приватные каналы и каналы с решеткой немного разные вещи. При подписке на приватный канал на ваш бэкенд отправляется дополнительный AJAX запрос от клиента Центрифуги — чтобы ваш бекенд вернул подпись (на основе секретного ключа который знают только Центрифуга и ваш бэкенд), разрешающую клиенту подписку на этот канал. Каналы с решеткой позволяют этого лишнего запроса на бэкенд избежать. UserID при подключении также подтверждается HMAC SHA-256 токеном на основе секретного ключика, который вы генерите на бэкенде, валидный токен говорит Центрифуге о том, что при подключении был передан корректный UserID. Поэтому пока этот ключ не известен чужой UserID вы не передадите. В этой статье я про это не писал, потому что это было в предыдущих. Но вообще обо всех параметрах и подписях лучше начинать смотреть вот отсюда .
Пользователь подписывается на канал personal_messages#2456 — где 2456 это ID пользователя (решетка это спец символ в Центрифуге, который запрещает другим юзерам подписываться на этот канал, в принципе можно и без нее обойтись — просто personal_messages2456, но обычно на персональные каналы другим подписываться не дают). Соответственно на бэкенде вы название этого канала для юзера знаете и отправляете сообщение в него. Redis тут никак не участвует (Центрифугу можно запустить и без Редиса — более того по умолчанию Redis не используется).
Привязка сессии пользователя к бэкенду никак не затрагивается в такой схеме. Для вас пользователь остается точно таким же как был до этого — просто теперь он еще соединен дополнительным постоянным коннектом с Центрифугой, от которой будет получать новые сообщения, отправленные вами с бэкенда в Центрифугу. Например, пользователь совершает какое-либо действие на сайте — пусть это будет добавление нового комментария. При этом этот комментарий вы отправляете на ваш бэкенд как и всегда — обычным или AJAX POST запросом. Соответственно при этом на бэкенд прилетает стандартный запрос от пользователя (который определяется вашим бэкендом стандартным для PHP способом). После валидации и сохранения комментария — отправляете его в нужный канал. Главное правильно организовать каналы. В моем понимании sticky sessions — это проксирование запросов клиентов на один и тот же инстанс бэкенда, поэтому возможно я не до конца понял вопрос и ответил не на него:)
У меня демо инстанс работает и пароль (demo) подходит, в 3 браузерах проверил на всякий случай — может, опечатались?
Приятно слышать! Да, к сожалению, вебсокеты работают именно так — было бы здорово иметь возможность нативным способом мультиплексировать соединения в одно, но пока ее нет. Поэтому и возникают мысли про особенности HTTP/2 – если в вашем случае большое кол-во соединений из разных вкладок это проблема, то возможно стоит посмотреть в сторону использования HTTP-транспортов SockJS вкупе с HTTP/2 сервером? Центрифуга научится HTTP/2 в ближайшее время — как только Go 1.6.1 зарелизится — собственно транспорты вроде eventsource должны будут работать через одно соединение из разных вкладок. Возможно, что за последним Nginx-ом уже сейчас можно по HTTP/2 с Центрифугой общаться — но я пока не пробовал. Кстати, надеюсь, что в какой-то момент в будущем Centrifugo постепенно уйдет от SockJS, но это пока не скоро. Мы у себя crosstab и аналогичные решения не пробовали, потому что проблемы такой пока не стояло.
Не за что:) Я из статьи не очень хорошо понял, почему вебсокеты отпали как вариант. Если только из-за слабой браузерной поддержки, то оба решения, озвученных выше, используют fallback HTTP-транспорты, в том числе и long-polling (xhr-polling). Более того у нас 95% пользователей уже могут подключиться по вебсокетам (возможно в вашем случае эта цифра меньше, зависит от аудитории сайта). Если вы видите еще какую-то проблему с вебсокетами и просто не желаете их использовать — то их просто можно отключить и использовать только HTTP — xhr-streaming, eventsource, xhr-polling и более изощренные для совсем старых браузеров (iframe-htmlfile, jsonp-polling).
Привет, 1000 человек онлайн это совсем не много — например у нас Centrifugo отъедает только 1% одного ядра CPU и 200мб памяти с 1к пользователями онлайн. Так что та же Центрифуга или dklab_realplexor, который часто упоминается в постах о PHP (в том числе и том, на который вы давали ссылку в тексте статьи), могут стать для вас лучшим выбором в конечном итоге.
Нет, у меня честно говоря даже и цели такой не было и нет. Вроде бы судя по описанию vertx — это реал-тайм фреймворк. Центрифуга немного другого рода решение — отдельный сервер, менее гибкий по сравнению с любым фремворком, я думаю, но более простой в использовании.
Сложно сказать, у нас нагрузки на Центрифугу практически нет — так что отвечаю из каких-то абстрактных соображений. В производительности скорее всего немного потеряете, если поместите за Nginx, но зато приобретете некоторый набор опций, которые можно будет подкрутить, ну и балансировку, если нужна. Еще так или иначе нужен какой-то прокси, чтобы проксировать клиентов, использующих polling-транспорты SockJS на один и тот же инстанс Центрифуги (возможно вам хватит одного инстанса или можно polling-транспорты не использовать, если не нужна поддержка совсем старых браузеров). Единственный случай серьезной нагрузки, который пока на данный момент есть — это 50 тыс. пользователей онлайн — там 2 инстанса Центрифуги за ELB. И есть небольшой race condition, который при нагрузке вылезает, приводящий к дисконнектам клиентов, – он починен в мастере, на днях сделаю релиз.
Пожалуйста:) На самом деле не совсем корректно сравнивать Centrifugo с Socket.IO – Центрифуга использует SockJS (аналог Socket.IO) как транспорт для сообщений между браузером и Centrifugo, используя всевозможные HTTP транспорты, когда не удается установить Websocket соединение, ну и все на этом. В остальном это отдельный продукт со своей внутренней механикой и встроенными возможностями.
я честно говоря думал, что это просто вброс, на который не нужно отвечать:) Во-первых – это 1000 сообщений, а не одно, во-вторых — на каждое из 1000 отправленных сообщений в реквесте формируется результат выполнения в JSON-е ответа. И я сравниваю реализацию Центрифуги на 2-х разных языках, а не языки.
Я вижу возможное будущее Центрифуги как отказ от SockJS в определенный момент, когда не останется проблем с подключением из браузера через Websocket и возможно добавление какого-либо TCP транспорта для более удобного общения из небраузерной среды. Но пока это только теория:) А как у вас по plain TCP общение происходит? как сериализуете данные?
Но, честно говоря, я сам в этот документ пока не вникал – знал только о его недавнем появлении:)
Пуш в Service Workers планируем, да — но только когда примут общий драфт для браузеров, чтобы не завязываться только на Хром и GCM, вот issue уже стоит. Но когда примут драфт пока не ясно.
Про unix socket: в Go функция
ListenAndServe, которая запускает HTTP-сервер, слушает tcp адрес, поэтому я не могу утверждать, что если логику этой функции вынести в проект и использовать unix-сокет все будет корректно работать.У меня демо инстанс работает и пароль (demo) подходит, в 3 браузерах проверил на всякий случай — может, опечатались?