LINUX.ORG.RU

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

 ,


1

1

Добрый день всем!

Други, помогите пожалуйста определить степень нагруженности будущего Веб-проекта по следующим данным: максимальное число Интернет-пользователей: около 500 максимальное число зарегистрированных пользователей: около 20000 максимальный объём БД: около 36 ТБ (не гигабайт, а терабайт). интенсивность нагрузки от пользователей: неизвестно. тип нагрузки: расчёт научных величин, трасс, траекторий исходя из начальных данных, хранимых в БД.

Можно ли по этим данным говорить о Веб-проекте, как о высоконагруженном и применять к нему методы построения высоконагруженных систем с несколькими фронтами (nginx), несколькими бек-ендами - DBMS, несколькими бек-ендами с PHP (короче по этой статье https://ruhighload.com/post/Архитектура+высоких+нагрузок) или нет?

Спасибо всем.

Ответ на: комментарий от letni

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

Ramirezkiv2 ()

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

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

kiotoze ★★★★ ()
Ответ на: комментарий от kiotoze

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

deep-purple ★★★★★ ()
Ответ на: комментарий от kiotoze

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от deep-purple

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

Ramirezkiv2 ()

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

zolden ★★★★★ ()
Ответ на: комментарий от Ramirezkiv2

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

umren ★★★★★ ()
Ответ на: комментарий от zolden

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

Ramirezkiv2 ()
Ответ на: комментарий от umren

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от zolden

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

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

Ramirezkiv2 ()
Ответ на: комментарий от no-such-file

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

Ramirezkiv2 ()
Ответ на: комментарий от no-such-file

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

Да

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

Да

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

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

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 3)
Ответ на: комментарий от no-such-file

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

Ramirezkiv2 ()
Ответ на: комментарий от no-such-file

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

Ramirezkiv2 ()

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

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

x3al ★★★★★ ()
Ответ на: комментарий от x3al

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

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

x3al ★★★★★ ()
Ответ на: комментарий от x3al

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

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

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

Ramirezkiv2 ()
Ответ на: комментарий от Ramirezkiv2

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от Ramirezkiv2

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от Ramirezkiv2

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

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

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

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

anonymous ()
Ответ на: комментарий от umren

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

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

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

q13 ()
Ответ на: комментарий от q13

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

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

umren ★★★★★ ()
Ответ на: комментарий от umren

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

q13 ()
Ответ на: комментарий от anonymous

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

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

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

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

Ramirezkiv2 ()
Ответ на: комментарий от no-such-file

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

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

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

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

Спасибо.

Ramirezkiv2 ()
Ответ на: комментарий от no-such-file

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

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

Ramirezkiv2 ()

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

Pyzia ★★★★★ ()
Ответ на: комментарий от Pyzia

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

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

Ramirezkiv2 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.