Определение нагрузки на Web-приложение

Примерно вторая степень

Отлично. Теперь я знаю, как степень нагрузки у моего будущего проекта. А интересно сколько всего степеней существует?

Мне кажется, он троллит.

Не может быть, я верю в Анона и его честность. Без паники, пока что всё идёт по плану.

методы построения высоконагруженных систем с несколькими фронтами (nginx)
максимальное число Интернет-пользователей: около 500

начни с одного nginx

Плюсую. Просто делать сразу так, чтобы потом можно было горизонтально размазаться. И как только понадобится — вводить доп сервера.

Ясно. Теперь я понял, что 500 пользаков - это с гулькин нос. Но мастер, можно ли я начну с одного веб-фронта, одного сервера приложений (php, python или C) и одного бек-енда MySQL?

Очень хотелось бы узнать как так сразу делать «так» поподробнее?

nginx upstream (для начала один пхп-бекенд) в том пхп-бекенде мастер и слейв два соединения с БД (кстати в самом начале по факту может оба коннекта ссылаться на одну и ту же БД легко), пока тоже только два. Позднее, например, мастер один будет всегда, а слейвов несколько - раунд-робином их выбирать при старте приложения. Читать с слейвов (ну кроме автоинкрементов например), писать в мастер, использовать транзакции. Вот это все искаропки есть в фреймворках. Какой именно выбирать, я советовать не собираюсь — это во первых дело вкуса, а во вторых технических нюансов.

можно
по базе - глянь на постгрес

Можете назвать хотя-бы какие-то фреймворки в которых есть выше обозначенный функционал? ПС: насколько трудоёмко будет сделать бекенд не на пыхе, а на сях?

максимальное число Интернет-пользователей: около 500

Вообще ни о чём не говорит. Нужно знать сколько запросов в минуту, а не количество пользователей.

Теперь я понял, что 500 пользаков - это с гулькин нос

Ничего ты не понял. Одно дело если 500 пользователей читают html отправляя 500 запросов за 10 минут, и совсем другое если 500 пользователей долбят какое-нибудь rest api по 500 запросов в секунду.

Аааа, теперь я всё понял: очень важен сам тип запросов от пользователей. Но, уважаемый, как мне понять сколько запросов в минуту у меня будет от предполагаемого количества одновременных пользаков, если всё что мне известно - это цифра 500 и что они будут вводить на фронтах начальные данные, а по ним приклад на бекендах с СУБД будут расчитывать то что нужно? API к сайту предполагается делать, только хорошо, я спрошу по-другому: сколько и каких ресурсов мне надо, если нагрузка будет действительно по 500 запросов в секунду? Есть ли на Просторах калькулятор/конфигуратор какой-нить, который считал бы ИТ-архитектуру Web-приложения?

500RPS/TPS даже калькулятор Электроника МК-61 потянет
У тебя там порнохостинг чтоли и видео в базе хранится?

берешь vps за 5$, все что ты там хочешь он потянет, главное крути там node.js или go, тогда на все хватит памяти и цпу

Месье знает толк в порнохостинге? Если бы так было, то причём тут мои 500 пользователей? Нет, не угадали. Тогда мне непонятно, почему месье «no-such-file» пытался испугать меня 500 запросами в секунду? Или это было 500 запросов в секунду от каждого от 500 пользователей? Я думаю, что такого не будет точно. База будет хранить числовые данные о примерно 4-х тысячах объектов, положение которых нужно будет отслеживать. Также пользователи этой системы периодически будут хотеть знать прогнозы о движении какого-либо объекта на несколько суток вперёд или наоборот - потребуют данные о положении за последние 6 месяцев. Как-то так.

Не можем пользоваться хостингом - ибо всё должно находится в нашем ЦОДе по ТЗ. Всякие фреймворки - не надо, ручками надо писать иначе в чём смысл программирования?

если всё что мне известно - это цифра 500 и что они будут вводить на фронтах начальные данные, а по ним приклад на бекендах с СУБД будут расчитывать то что нужно?

Зависит от того как организован сам веб-сервис. Точно, кончено не посчитаешь, но можно прикинуть какого порядка будут цифры.

если нагрузка будет действительно по 500 запросов в секунду?

Ну можно прикинуть - если один запрос 100мс (вполне реально для апи), то за 1 секунду 1 поток прокрутит 10 запросов. На самом деле больше, т.к. есть ещё время на простой при вводе-выводе. Т.е. можно рассчитывать на 20-30-40 запросов в секунду на 1 ядро. Соответственно 500rps нужно ~ 20-30 ядер. По памяти, если на пыхе, то от 30Мб на один php-fpm умножаем на 500 - ~15Гб минимум.

500RPS/TPS даже калькулятор Электроника МК-61 потянет

На статике или из кэша. А теперь попробуй на реальных данных из БД, да ещё что-нибудь посчитать.

Уважаемый, мы же сейчас про вычислительный бекенд говорим? Если да, то могу ли я эти 20-30 ядер разделить на 2-3 сервера?

И ещё, если я буду для вычислений использовать не Пых, а Питон или Си, то как посчитать количество нужной оперативки?

Ага, и не говорите, он бы ещё счёты мне предложил поиспользовать. Или палочки для счёта.

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

Если да, то могу ли я эти 20-30 ядер разделить на 2-3 сервера?

Да

сможем ли мы решить проблему путём добавления дополнительных серверов на уровень вычислительного бекенда?

Да

использовать не Пых, а Питон или Си, то как посчитать количество нужной оперативки?

Существенно ничего не изменится. Может чуть меньше памяти. Я же сказал

Точно, кончено не посчитаешь, но можно прикинуть какого порядка будут цифры

Это прикидка по порядку величин, а не по точным значениям.

Ok. Тогда ГРАН мерси, Уважаемый, за прояснение по данному вопросу.

всмысле какие фреймворки? ты о чем? там все голое и сырое

Nobody ever got fired for picking Java (c)

не тот тред, ну ты понял

всмысле какие фреймворки? ты о чем? там все голое и сырое

Какие фреймворки? У кого это там всё голое и сырое, а?

ловите наркомана

Так вот, уважаемый, мы берём время выполнения запроса - в 100 мс, как догму или это достаточно усреднённое значение для всех типов запросов ввода/вывода? Разве не бывает таких запросов, выполнение которых занимает 1000 мс?

максимальный объём БД: около 36 ТБ

Объём RAM обычно не выше 2ТБ, следовательно, у тебя бигдата если твою базу нельзя банально разделить на независимые друг от друга части.

Точно, я об этом чего-то и не подумал сразу. А неужели сервера СУБД тащат всю базу целиком с диска в память, а не подгружают данные по мере надобности? Таки я совсем не знаю можно её разбить или нет. Я не против её разбивания - вроде бы современные СУБД умеют разбивать данные одной БД по разным сервакам в кластере - только не помню как этот механизм называется.

подгружают данные по мере надобности

Где в твоём ОП-посте сказано, что нужны не все данные? Ну, это если представить, что у тебя есть реальная задача и в ОП-посте действительно что-то осмысленное, а не бред.

Встречный вопрос - а где в моём посте сказано, что нужны все данные из базы ОДНОВРЕМЕННО, ВСЕГДА и СРАЗУ?

Про реальную задачу - всё расписано в самом начале треда. Где там вы увидели что-то похожее на бред или незнакомое слово?

Я пытаюсь выяснить запихивает ли СУБД всю базу в память или нет, а вы упрекаете меня в бреде, вместо того, чтобы прямо ответить на вопрос, что так делается всегда во всех СУБД или нет, это не обязательно. В чём проблема то?

Разве не бывает таких запросов, выполнение которых занимает 1000 мс?

Бывает, но лучше так не делать. Сложные запросы лучше разбить на несколько простых, чтобы время обработки было минимальным. Вообще чем меньше - тем лучше, как не трудно догадаться. Это улучшает ситуацию с перегрузкой, т.к. лучше чтобы у пользователя за 1 сек прошёл хотя бы 1 «тонкий» запрос (и он наблюдал прогресс) чем ни одного «толстого».

100мс - типичное время запроса для ситуации «проверить токен и сделать средней сложности запрос к БД». Потыкай любое апи и будет примерно такой результат +-копейки.

Чтобы ты понимал, я считал для ситуации без проседаний, т.е. все запросы обслуживаются за указанное время. Если, к примеру приходит в 2 раза больше пользователей чем планировалось, то время запроса увеличится тоже в 2 раза и т.д. пока пользователи не начнут отваливаться по таймауту.

Я пытаюсь выяснить запихивает ли СУБД всю базу в память или нет

Нет конечно, в этом и есть смысл СУБД, а иначе можно просто читать все данные прямо в программу и вертеть как хочешь. Для СУБД нужно обеспечить память под индексы, буферы и кэш.

Разве не бывает таких запросов, выполнение которых занимает 1000 мс?

Ты там, наверху, что то про научные расчёты излагал :) no-such-file дал тебе практически формулу - подставляй свои цифры и смотри.

Обобщая - прогнозы дело не благодарное :)

К примеру мы ничего не знаем о требованиях к доступности. Если ты птичек (настоящих, живых) считаешь - это одно, а если «опасные объекты возле дальней границы С400» - другое :) Как твои данные организованны вот прямо сейчас? 36Тб хоть и не ужос-ужос уже, но объём всё же очень серьёзный ... ну и т.д.

главное крути там node.js или go, тогда на все хватит памяти и цпу

Поясни почему ты решил советовать это?!

П.П.Сю стёб что ль?

потому что они жрут мало памяти, можно поднять еще рядом базу и нормально жить с этими 500 пользователями о которых идет речь?)

джаву ты туда не запихнешь, пхп тоже из-за модели исполнения, ну и так далее

у меня ХостинГ с ларой (64 mb oзу) 950 онлайн тащит на ура. B2b сервис с постоянными обращениями к Mysql через ORM, который по суевериям зло)) так что дело скорей в руках. Я уверен что подобное и на Django + Postgresql реально сделать.

у меня ХостинГ с ларой

а ты знаешь разницу между 64 мб на 1 скрипт (куда не входит база) и 512 на твоем vps?

да ты прав, тупанул

К примеру мы ничего не знаем о требованиях к доступности.

Из ТЗ: оперативность доступа к информации - 15 минут. ПС: это не mission-critial и не business-critical система и я - не из банка.

Ты там, наверху, что то про научные расчёты излагал :) no-such-file дал тебе практически формулу - подставляй свои цифры и смотри.

Так я подставил уже и посчитал и у меня получилось, что система состоит из оборудования на трёх уровнях: 1. Веб-сервера 2. сервера приложений 3. Сервера управления БД На каждом уровне - кластер - либо с балансировкой либо отказоустойчивый. На каждом сервере по два проца с не менее чем 12-ю ядрами. Память ещё не посчитал. В-общем обычная такая базовая конфигурация. Если столкнёмся с проблемами в производительности - то будем масштабировать на каждом уровне либо увеличением мощности серверов либо количеством серверов. Стоп. Нет. Не будем. Мы же не должны вываливаться за пределы максимальной планируемой нагрузки. Нам никто не даст докупить сервера или CPU/память. Печаль.

100мс - типичное время запроса для ситуации «проверить токен и сделать средней сложности запрос к БД»

У меня уточняющий вопрос: 100 мс - это запрос от момента отправки данных от Интернет-юзера до момента получения им ответа или это время от момента начала обработки запроса PHP-прикладом с обращением к СУБД?

И второй вопрос - вот здесь: https://ibb.co/g8drS5 - планируемая архитектура серверов под Web-приложение. Ранее, я намечал на уровне Web-серверов использовать Apache или Nginx, а на уровне серверов приложений - PHP.

Можно ли на уровне Web-серверов использовать Nginx - для отдачи статического контента (его будет очень мало) и для балансировки нагрузки на сервера приложений, а не уровне серверов приложений использовать Apache+PHP с обращениями к СУБД для обработки динамики?

Спасибо.

Можно. Однако так и делают.

Соответственно 500rps нужно ~ 20-30 ядер. По памяти, если на пыхе, то от 30Мб на один php-fpm умножаем на 500 - ~15Гб минимум.

Уважаемый, а есть ли метода подсчитать количество необходимых ресурсов для отдачи статики на Nginx? И вообще сколько максимально без просадки производительности может вытянуть Nginx?

Не знаю, у меня больше 6мс не получалось запросы делать.

Не знаю, у меня больше 6мс не получалось запросы делать.

Запросы были с извлечением данных из БД?

Почему ты не трясёшь програмистов, которые тебе весь этот твой бэкенд будут писать? Они и должны тебе сказать, сколько запросов в секунду будет и прочие детали реализации, если не точно, то намного точнее, чем астрологи с ЛОРа.

Почему ты не трясёшь програмистов, которые тебе весь этот твой бэкенд будут писать? Они и должны тебе сказать, сколько запросов в секунду будет и прочие детали реализации, если не точно, то намного точнее, чем астрологи с ЛОРа.

Пися, ты в своём уме? Прогерам на запросы в секунду с глубокой колокольни и они мне ничего не должны. А если ты не в состоянии ответить на мои простые вопросы, то нех здесь истерить по этому поводу - иди книги читай, истеричка.