KY
а это вебсокеты?
Size: a a a
2021 June 30
РЗ
нет, рест
РЗ
http
РЗ
(пока что. Кто знает, может и впилят вебсокеты/лонгполлинг какой-нибудь, но пока нет новостей)
KY
ну для начала, в тему предыдущих сообщений тебе надо будет понять суммарный исходящий рпс твоего сценария. может быть такое что 100 млн юзеров будут делать около тысячи рпс в пике, в таком случае тебе может не потребоваться вообще никакая распределенная система для рест, а просто 1 инстанс
A
на самом деле нужно учесть, иногда сессии пользаков кешируются или как-то используются. тогда например 100500 rpc и 1000 пользаков != 100500rpc и 100500 пользаков. Они в кеше могут не уместиться или деградировать
KY
чтобы понять сколько арендовать чего, тебе надо это первым делом оценить. прогони а небольшой нагрузке на тех ресурсах которые есть, оцени утилизацию, может получится быстро что то соптимизировать. если у тебя много csv - это дешево
KY
после оценки утилизации, можно помасштабировать нагрузку и посмотреть зависимости
KY
чтобы увеличивать нагрузку поэтапно ты можешь использовать throughput shaping timer например, в него заложить ступени. а количество тредов задать такое чтобы с запасом хватило на реализацию этого рпс по формуле Threads=RPS*Max_Total_Response_Time_of_Scenario. то есть то за сколько проходит у тебя сценарий умноженное на то сколько раз в секунду он должен выполняться + запас это коилчество тредов
KY
свой csv для каждого инстанса норм практика, если хочется чего то поудобнее - можно взять редис например или бд
KY
Разную бизнес логику можно сунуть в один тред если ты сможешь легко менять контексты и сможешь учесть что на разные запросы могут быть разные рпсы Например логинится будет каждый юзер, а вот отправлять не каждый, например молчуны какие нибудь или есть обратный кейс, активные чат юзеры
VG
согласен.
Если для каждого активного пользака есть своя сессия или выделенные объекты в памяти - и правда, становится важно.
Но даже в такой ситуации лучше знать, сколько времени живёт сессия и создавать этот миллион сессий из небольшого количества потоков.
Установить сессии и забить на них, а через 10 минут, когда они умрут по таймауту - создать новые.
Если для каждого активного пользака есть своя сессия или выделенные объекты в памяти - и правда, становится важно.
Но даже в такой ситуации лучше знать, сколько времени живёт сессия и создавать этот миллион сессий из небольшого количества потоков.
Установить сессии и забить на них, а через 10 минут, когда они умрут по таймауту - создать новые.
VG
вот с вебсокетами, наверное, так не получится.
там реально коннекты нужно держать
там реально коннекты нужно держать
VG
@login40k верно ведь?
или тоже можно из одного потока много сессий установить?
или тоже можно из одного потока много сессий установить?
KY
для нагрузочного теста время жизни сессии может быть не важно с точки зрения полезной нагрузки. тогда можно конфигурацией расширять время жизни сессии. но это выколотая точка при оценке - тут надо проверить работу сессий отдельно, знать что если сессия чаще открывается, то системе от этого не хуже
KY
по вебсокетам всё просто, можно держать N коннектов без полезной нагрузки, чтобы система на них выделяла ресурсы и резервировала коннекты у себя, а X коннектов будут делать грязные делишки
jj
и юзать рантайм-контроллер
KY
ну например
KY
или тупо таймер и сокет close
KY
вот тут проблема, 100 млн пользоваталей, способны сделать 100 млн. коннектов. это наверное предполагается не единовременное использование системы в один момент времени, но в целом 100 млн коннектов это 100 млн портов, на одной машине такого коилчества свободных дескрипторов может не быть