AL
я подозреваю, что вопрос про управление ресурсами внутри одного сервера
Size: a a a
2020 April 19
TS
Автоскейлинг настроили, буквально на этой неделе делали load testing прекрасно скейлится при росте запросов
От этого пропадают симптомы и проблема перестает быть явной, но это не избавляет от оптимизации принятия нагрузки в приложении. Абстрактеые 1000 запросов в секунду, которые вполне способен обработать сервер, будут быстрее обрабатываться с параллелизмом 100 и очередью 900, чем все сразу.
ES
А есть кусочек кода который это демонстрирует? Приходят запросы, делают select из базы, мне следующие 100 начинать обрабатывать когда предыдущие прям ответ отдали (+350мсек)? Или когда только запустили select но не получили ответ уже убирать его из очереди?
A
А есть кусочек кода который это демонстрирует? Приходят запросы, делают select из базы, мне следующие 100 начинать обрабатывать когда предыдущие прям ответ отдали (+350мсек)? Или когда только запустили select но не получили ответ уже убирать его из очереди?
то уже зависит от реализации очереди. Можно настроить на максимум 100 запросов всегда, можно сделать на максимум 100 запросов в секунду, вариантов много.
Есть еще всякие решения которые это делают вне приложения, а между базой и приложением
Есть еще всякие решения которые это делают вне приложения, а между базой и приложением
TS
CountingSemaphore, и я ответил, что как допишем кит, то будем тестами заниматься и оптимизациями, я конечно по ходу это autocannon проверяю. Всего 2 недели пишем, имей совесть... )))
ES
то уже зависит от реализации очереди. Можно настроить на максимум 100 запросов всегда, можно сделать на максимум 100 запросов в секунду, вариантов много.
Есть еще всякие решения которые это делают вне приложения, а между базой и приложением
Есть еще всякие решения которые это делают вне приложения, а между базой и приложением
В какой момент убираем из очереди - когда послали в базу запрос или когда дождались ответа?
TS
А есть кусочек кода который это демонстрирует? Приходят запросы, делают select из базы, мне следующие 100 начинать обрабатывать когда предыдущие прям ответ отдали (+350мсек)? Или когда только запустили select но не получили ответ уже убирать его из очереди?
Когда отдали, не обязательно 100 к 900, это нужно настраивать в зависимости от специфики прикладного кода, нужно планировать эксперимент и находить седловую точку
TS
В какой момент убираем из очереди - когда послали в базу запрос или когда дождались ответа?
Есть N каналов обслуживания и очередь с длиной M, есть таймаут обработки и таймаут ожидания
A
В какой момент убираем из очереди - когда послали в базу запрос или когда дождались ответа?
В большинстве случаев из очереди убирается в момент посылания запроса. Но новый запрос из очереди береться на выполение, когда один из обрабатываемых в данный момент закончил свои дела
ES
Есть N каналов обслуживания и очередь с длиной M, есть таймаут обработки и таймаут ожидания
Да, прикольно, я поэкспериментирую у нас
TS
Да, прикольно, я поэкспериментирую у нас
Можно почитать теорию СМО - системы массового обслуживания
ES
У меня было на 5м курсе )
TS
Это паттерн появившийся в конце 19 века на фабликах и разработанный параллельно в США и СССР в середине 20 века
TS
Ну вот апачь не поддерживал это, а нгинкс сразу на смо строился
TS
TS
у меня без оптимизации сейчас нода дает на 1 процессе 42k, а стартер кит 30к, это без доступа в базу, просто на отдаче статической html
TS
старый ноут dell xps13, i7, на котором еще pg, chrome, кучу каких-то контейнеров в бекграунде, и вообще непойми шо
TS
ab ничего не показывает, бери autocannon
Y
Что значит лимит http? Вы с ограничением по каналу сети не путаете?
TS
ну это тесты на локалхочте, когда комп сам себя грузит, это вообще ни о чем