LINUX.ORG.RU

История изменений

Исправление micronekodesu, (текущая версия) :

Обычно в херак-херак принято по большому пальцу прикидывать допустимую нагрузку и жестко резать всё что выше.

Обычно разработчики и эксплуатация знает сколько запросов может нормально обслужить их приложение. И это не только "прикидывания", но и результаты нагрузочных тестирований и вообще опыт в эксплуатации. И никто не скажет "ну короч мой сервер там ну так нормальна пользователей выдержит но если вот срипты не срипты то тогда не но тоже норм будут ответы". Я знаю с какого количества запросов мой сервис (а точнее каждый компонент) начинает деградировать. И никто не режет то что выше, а добавляют мощностей, потому что только идиот будет отсекать трафик, наоборот одна из основных задач любого это сделать его сервис популярнее.

В моем старом проекте время работы скриптов на тяжелых запросах было раз в десять больше, чем БД. Однако, на легких запросах скрипты работали примерно как БД. Вот и придумай мне теперь, сколько одновременно пользователей сервер может обрабатывать.

На мой старый проект было выделено стопицот ядер. Угадай сколько виртуалок у меня было.

Такая картина может наблюдаться разве что на очень простых сценариях. При малейшем усложнении уже оказывается, что разные запросы занимают разные ресурсы, сервер потенциально может обслужить и 20-30 клиентов, но в самом худшем типовом сценарии — только 10.

Если писать немасштабируемые лапшемонолиты то да.

Исходная версия micronekodesu, :

Обычно в херак-херак принято по большому пальцу прикидывать допустимую нагрузку и жестко резать всё что выше.

Обычно разработчики и эксплуатация знает сколько запросов может нормально обслужить их приложение. И это не только "прикидывания", но и результаты нагрузочных тестирований и вообще опыт в эксплуатации. И никто не скажет "ну короч мой сервер там ну так нормальна пользователей выдержит но если вот срипты не срипты то тогда не но тоже норм будут ответы". Я знаю с какого количества запросов мой сервис начинает деградировать. И никто не режет то что выше, а добавляют мощностей, потому что только идиот будет отсекать трафик, наоборот одна из основных задач любого это сделать его сервис популярнее.

В моем старом проекте время работы скриптов на тяжелых запросах было раз в десять больше, чем БД. Однако, на легких запросах скрипты работали примерно как БД. Вот и придумай мне теперь, сколько одновременно пользователей сервер может обрабатывать.

На мой старый проект было выделено стопицот ядер. Угадай сколько виртуалок у меня было.

Такая картина может наблюдаться разве что на очень простых сценариях. При малейшем усложнении уже оказывается, что разные запросы занимают разные ресурсы, сервер потенциально может обслужить и 20-30 клиентов, но в самом худшем типовом сценарии — только 10.

Если писать немасштабируемые лапшемонолиты то да.