BG Development


  Reply to this topicStart new topicStart Poll

> Load Test, Server Polling
uccie
Публикувано на: 03-01-2017, 15:48
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



Имам мобилно приложение за симулация на решения, което е реализирано със елементарна client-server-client архитектура; сървърът предоставя REST-API, променя състояния и актуализира ресурсите в PostgreSQL. Може да си го представите като tic-tac-toe (Х и 0), но с доста усложнения: множество таймери, недетерминистично определяна на реда, трима играчи и т.н.). Сървърът е написан на Django (Django REST framework).

В началото бе взето (грешно!) решение да не се използват websockets или някаква друга push-технология, а хамалски да се пита сървърът - "Дай ми симулация Х", "Дай ми симулация Х", "Дай ми симулация Х". Клиентът, Android с RxJava, е отговорен да анализира дали има промяна в Х и да спре request-ите ... грозен polling, дори не е long polling. Така ... станалото, станало.

През следващите няколко месеца ще се организират симулации с между 20 - 100 човека и трябва да съм сигурен, че сървърът няма да умре. Очаквам максимално между 100-120 requests per second.

Ще съм много благодарен, ако някой може да ми предложи някакъв tool, който е лесен за използване и може да ми свърши работа за стрес-тестове. JMeter вариант ли е?

Каква сървърна конфигурация е разумна за гореописаната ситуация?





PMEmail Poster
Top
Bender
Публикувано на: 03-01-2017, 16:06
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 4076
Регистриран на: 19.06.14



При нас се послзва нГриндер (1) обаче аз не съм се занимавал лично с него.

Решението да не се ползват хлебсокети не е грешно, а реализацията ви е грешна. Имам доста опит с асинхронни рест апита, и тук правилният подход не е да се прави полинг, а сървъра да казва: ок, заявката за симулация е приета, очаквам да е обработена след 30 секунди. Следователно клиента не полва като лудия шапкар, ами прави заявка след 30 секунди - ако симулацията е готова - всичко е ОК, ако не е - сървъра казва "пробвай пак след Ж секунди". От полинг смисъл няма.

1. https://naver.github.io/ngrinder/


--------------------
Живота е спагети, кода за да работи добре трябва да го наподобява - Дон Реба
...
Живеем в греховни времена, какво очакваш богоугоден и благочестив код ли? - Дон Реба
...
много положителна енергия черпя от вас двамата,единият комунистически девствен,другият яко яхнал асемблерните розови понита - saruman
...
Рано или късно усерите на Виндофс разбират че стоят от неправилната страна на хуя. - ici
PM
Top
uccie
Публикувано на: 03-01-2017, 16:21
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



QUOTE (Bender @ 03-01-2017, 16:06)
При нас се послзва нГриндер (1) обаче аз не съм се занимавал лично с него.

Решението да не се ползват хлебсокети не е грешно, а реализацията ви е грешна. Имам доста опит с асинхронни рест апита, и тук правилният подход не е да се прави полинг, а сървъра да казва: ок, заявката за симулация е приета, очаквам да е обработена след 30 секунди. Следователно клиента не полва като лудия шапкар, ами прави заявка след 30 секунди - ако симулацията е готова - всичко е ОК, ако не е - сървъра казва "пробвай пак след Ж секунди". От полинг смисъл няма.

1. https://naver.github.io/ngrinder/

Мерси, Бендер. Ще разгледам проекта.

Проблемът е, че симулацията е интеракция между различни клиенти, сървърът не знае кога ще е "готов".
PMEmail Poster
Top
uccie
Публикувано на: 03-01-2017, 17:52
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



Този nGrinder e много добър.
PMEmail Poster
Top
antubis
Публикувано на: 03-01-2017, 18:07
Quote Post



Име: Маруш Денчев
Група: Потребител
Ранг: Почетен член

Мнения: 1773
Регистриран на: 21.06.05



// off-topic
grindr е още по-добре. Google it.


--------------------
fuck their lack of originality and personality
fuck this travesty
fuck this new norm
fuck conformity
--------------------------------
Denchev.me
CakePHP Bulgaria
PMEmail PosterUsers Website
Top
uccie
Публикувано на: 03-01-2017, 19:25
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



QUOTE (antubis @ 03-01-2017, 18:07)
// off-topic
grindr е още по-добре. Google it.

Щом казваш. То пак си e load test, просто друг вид load.
PMEmail Poster
Top
FidelDahan
Публикувано на: 06-01-2017, 00:25
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2092
Регистриран на: 12.06.08



За да не се претовари сървъра евентуално полинга в клиента може да се направи да бъде с адаптивна честота в зависимост от response time на сървъра.

Също сигурно има смисъл и в сървъра да се ограничи паралелизма (примерно не повече от 64 HTTP threads в thread pool-a). По този начин при натоварване клиентите автоматично ще чакат по-дълго. Или пък ще получат някакъв timeout и трябва да да реагират с нов полинг request.
PMEmail Poster
Top
uccie
Публикувано на: 06-01-2017, 21:23
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



QUOTE (FidelDahan @ 06-01-2017, 00:25)
За да не се претовари сървъра евентуално полинга в клиента може да се направи да бъде с адаптивна честота в зависимост от response time на сървъра.

Също сигурно има смисъл и в сървъра да се ограничи паралелизма (примерно не повече от 64 HTTP threads в thread pool-a). По този начин при натоварване клиентите автоматично ще чакат по-дълго. Или пък ще получат някакъв timeout и трябва да да реагират с нов полинг request.

Мерси, FidelDahan! Това с адаптивния полинг е добра идея, но не знам дали ще стигне времето да се имплементира. Най-вероятно ще пуснем сървъра да скалира on-demand и ще му мислим след експериментите.

Едит: Пък може би само си въобразявам, че е голям проблем ... нямам представа.

Това мнение е било редактирано от uccie на 06-01-2017, 21:25
PMEmail Poster
Top
uccie
Публикувано на: 07-01-2017, 15:38
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



Изглежда, че всичко е ОК. Май цялата история беше "много шум за нищо". Без скалиране, с възможно най-смотаната машина, се достигат 231 транзакции за секунда.

Бендер, мерси още веднъж за nGrinder. Скоро не бях виждал софтуер, който работи толкова безпроблемно!

Това мнение е било редактирано от uccie на 07-01-2017, 15:39

Прикачена картинка (Кликнете на картинката, за да я увеличите!)
Прикачена картинка
PMEmail Poster
Top
uccie
Публикувано на: 11-01-2017, 19:43
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 537
Регистриран на: 16.10.12



Днес беше първият експеримент. Нямаше никакви проблеми със сървъра ... но разбира се големи проблеми с мрежата. Винаги ти го слагат там, където не очакваш.
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2015 | BG Development | All Rights Reserved
RSS 2.0