p
Alexander Bukarev
@IgorBespalchuk нашёл результаты PoC по LightStreamer-у, на AWS c5.large на 10000 соединениях при 5 update-ах/сек (на каждое соединение, т.е. всего 50k сообщений рассылали в секунду, сообщения разные по структуре и размеру, не все простые дельты) стабильно (гоняли 1.5 часа) загрузка была по CPU ~90% (были спайки до 95% иногда), память 3.7Gb
На t2.medium плохо себя вёл. На 3000 соединениях (5 update per sec) стабильно, а вот на 5000 соединениях (тоже 5/сек) через 15 минут начинал терять пакеты. Связано с тем, что кредиты выедать начинал на t2-машине. Отсюда вывод, что на t-instance использовать не стоит.
В целом результаты хорошие, учитывая что самописное решение на Go проиграло и по памяти, и по CPU (потому что LightStreamer хорошо оптимизировал своё решение, а мы не очень, видимо).
По цене смотрю сейчас, совсем не космос, довольно дёшево, в районе $10k в год. Но мы тогда засомневались именно из-за их способа расчёта стоимости при "спайках" (они считать умели только по max(concurrent-connects) по месяцу, т.е. ценник мог в 4-5 раз вырасти. Непредсказуемость нас смутила.
На t2.medium плохо себя вёл. На 3000 соединениях (5 update per sec) стабильно, а вот на 5000 соединениях (тоже 5/сек) через 15 минут начинал терять пакеты. Связано с тем, что кредиты выедать начинал на t2-машине. Отсюда вывод, что на t-instance использовать не стоит.
В целом результаты хорошие, учитывая что самописное решение на Go проиграло и по памяти, и по CPU (потому что LightStreamer хорошо оптимизировал своё решение, а мы не очень, видимо).
По цене смотрю сейчас, совсем не космос, довольно дёшево, в районе $10k в год. Но мы тогда засомневались именно из-за их способа расчёта стоимости при "спайках" (они считать умели только по max(concurrent-connects) по месяцу, т.е. ценник мог в 4-5 раз вырасти. Непредсказуемость нас смутила.
а какое поведение у LightStreamer на медленных клиентах?