1 Востаннє редагувалося ping (08.06.2017 10:31:11)

Тема: Як правильно обрати інструменти для рішення такої задачі?

Є таке тестове завдання ( python ) :

Написати менеджер todo ( rest api ) який зможе підтримувати 100 одночасних підключень(читання/запис 50:50)

Які інструменти (фреймворки , бази) доречно обрати для його рішення?

2

Re: Як правильно обрати інструменти для рішення такої задачі?

https://medium.freecodecamp.com/million … 5c137af319

https://stackoverflow.com/questions/123 … onnections

Можна ще багато чого нагуглити при бажанні. Але 100 одночасних підключень - це зовсім мало. І як його розуміти? Це ж не буде 100 відкритих курсорів бази даних чи ще якась біда. Навіть якщо й 100 юзерів в одну й ту ж долю секунди нажмуть "сабміт", то на сервері вони нехай собі почергово обслуговуються, або через якийсь пул тредів/конекшнів і т.д., наприклад максимум 10 штук. Думаю, можна знайти уже готові рішення і подивитися як хтось це вже зробив :)

3

Re: Як правильно обрати інструменти для рішення такої задачі?

Справа в тому що я просто написав на фласку і помістив за  uwsgi з кількома воркерами.

А мені айчар написала що не рішено, бо не виконана умова тримати кількість підключень.
я тестував через постман на 1000 одночасних put    - сервер навіть не відчув.
от і виникло питання - хто непра?

4

Re: Як правильно обрати інструменти для рішення такої задачі?

Варто б уточнити тоді, що саме вони розуміють під кількістю підключень. Може це типу параметр keep-alive? І тоді бачити чи витримує. Ось тут можна почитати - https://habrahabr.ru/company/xakep/blog/259845/

Подякували: ping1

5

Re: Як правильно обрати інструменти для рішення такої задачі?

Master_Sergius написав:

Варто б уточнити тоді, що саме вони розуміють під кількістю підключень. Може це типу параметр keep-alive? І тоді бачити чи витримує. Ось тут можна почитати - https://habrahabr.ru/company/xakep/blog/259845/

наприклад використовував https://www.getpostman.com/ -  Postman
сервер залишає Connection →keep-alive
ну і що?
як тільки запитів стає забагато - uwsgi сервер обриває "висяки"

6

Re: Як правильно обрати інструменти для рішення такої задачі?

Master_Sergius написав:

Варто б уточнити тоді, що саме вони розуміють під кількістю підключень.

Варіантів я бачу два:
1. це може бути або websockets, які тримають постійний конект;
2. або файлообмінник, де кожен із файлів може скачуватись досить довго.

Тобто підозрюю, що вас тестують на вміння працювати з асинхронними операціями.

7

Re: Як правильно обрати інструменти для рішення такої задачі?

ktretyak написав:
Master_Sergius написав:

Варто б уточнити тоді, що саме вони розуміють під кількістю підключень.

Варіантів я бачу два:
1. це може бути або websockets, які тримають постійний конект;
2. або файлообмінник, де кожен із файлів може скачуватись досить довго.

Тобто підозрюю, що вас тестують на вміння працювати з асинхронними операціями.


А REST є сенс застосовувати з постійними конектами?

кожен запит - stateless - незалежний - задав- отримав- відвалився.

хтось може навести широке виправдaне застосування REST по вебсокетах?

ну і які такі вебсокети для 100 навіть постійних підключень?

спеціально вивчив як це перевірити, встановив JMeter від Апача.

валю 100 ОДНОЧАСНИХ підключень в безконечному циклі, де кожне підключення робить два запити put and get

на слабенькому однопроцесорному VPS з 1 Гб пам1яті ,де  на бекенді SQLite (яка точно не вміє працювати з конкурентними запитами) .

і при цьому uwsgi тримає, а пам’ять зайняло аж 70%

8

Re: Як правильно обрати інструменти для рішення такої задачі?

ping написав:

А REST є сенс застосовувати з постійними конектами?

У вашому випадку з REST, дійсно лише другий варіант підходить. Я наводив приклади взагалі з тривалими конектами.

ping написав:

ну і які такі вебсокети для 100 навіть постійних підключень?

У випадку з вебсокетами, на боці сервера конектів може бути навіть мільйони. Якщо у вас є обліковий запис на github, наприклад, то можете пересвідчитись, що конект у вас буде постійним. Тобто, виходить, що скільки користувачів на github зараз онлайн, стільки і підключень.

Як перевірити конект для вебсокета на github: у Google Chrome відкриваєте github, натискаєте F12, шукаєте у тому вікні, що відкрилось, Network й перезавантажуєте сторінку. Перед вами буде список файлів з різними колонками (Name, Status, Type...). Відсортуйте по колонці Status, вгорі у вас буде 101 статус. У цьому ж рядку, у колонці Time буде показуватись "Pending" (очікування) завжди. Це і є той самий конект для вебсокетів.

Подякували: ping1