Комментарии 10
А будет ли успешно работать сервис при, допустим, 10000 соединений? Есть у кого-нибудь такой опыт?
я поднимал на домашнем компе 1.6кк коннектов, работало, но cpu был занят обработкой сети, на 10к проблем быть не должно, но зависит от имплементации сервера
Я не понял, коллега, 1.6кк — это сколько? 16000 соединений? Или больше полутора миллионов? Это не праздный вопрос. Мне просто интересно, как по нагрузке будет вести себя сервис? Будет ли он справляться? Откровенно говоря, я не делал таких жёстких испытаний.
Обычно под kk подразумевают миллионы.
да, мне было скучно, я поднял 40 виртуальных машин для клиентских приложений и одну виртуалку для сервера, 40 клиентов по 20к коннектов = 800к клиентских коннектов, и на сервере — 800к серверных, оперативы сожрало примерно 12 гигов, но все уперлось в старенький амд.
На таком количестве коннектов проц только занимался обработкой эвентов на соединениях и все было довольно неспешно, на 500к клиентов все работало прекрасно и проц не напрягался
На таком количестве коннектов проц только занимался обработкой эвентов на соединениях и все было довольно неспешно, на 500к клиентов все работало прекрасно и проц не напрягался
А почему между серверами не сделать взаимодействие через обычный сокет, это разве не будет эффективнее и проще — меньше данных будет передаваться или я ошибаюсь?
А длина токена именно 256 байт у гугл, не бит (я не знаю, просто удивила такая длина)?
оверхед на вебсокетах минимальный — пара байт для размера сообщения, что-то аналогичное все равно придется писать для обычных сокетов, а тут оно есть из коробки
256 это я конечно хватил. А вот длина 120 символов — это пожалуйста. Вот, например, что мне сегодня пришло от сервиса GCM: APA91bFCblOevBb33Y8yaLEpHvqx46lYXVrF1XlisUKcY7nevT09RrsZj-cBM9UbHUtsixEuTi-r1bkgDJdDK-HielBJ_5MxuaN786D6KyRmiDa85ARQZVw
Сейчас делаю аналогичный сервер на golang. Гоняю его тестирование на 10000 одновременных коннектах (соединение/отправка данных/получение данных/дисконнект). Расход памяти в районе 2 Мб. По процу — до 200% в пике.
Если экстраполировать, то текущий вариант, по моим прикидкам может обработать до миллиона обычных соединений.
Если экстраполировать, то текущий вариант, по моим прикидкам может обработать до миллиона обычных соединений.
Берется jms в качестве бека или любой брокер сообщений, вебсокеты или что угодно в качестве средства коннекта и все. Роутинг настраивается средствами брокера. Зачем велик то изобретать?
В брокере есть балансировка, роутинг, фильтрация и вообще что угодно. Сделано очень оптимизировано и поверх лог подобной базы… но это от реализации зависит.
Хотя по началу я тоже велик и тоже на вебсокетах пилил… но быстро опомнился, на третий день)
В брокере есть балансировка, роутинг, фильтрация и вообще что угодно. Сделано очень оптимизировано и поверх лог подобной базы… но это от реализации зависит.
Хотя по началу я тоже велик и тоже на вебсокетах пилил… но быстро опомнился, на третий день)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Websockets. Возможный подход по использованию