1. Создаем пустой ASP.Net Core сайт, параметры машины примерно как за $100 в мес. по средним тарифам. Сколько запросов в секунду вы сможете отработать Hello World? Примерно это 500, 5000, 50 тыс. или 500 тыс. Есть ли у вас примерное представление или вообще без понятия?
2. Добавляем запрос к базе через EF-Core по ключу. Пусть СУБД PostgreSQL. Как изменится скорость выдачи после этого?
Здравствуйте, Shmj, Вы писали:
S>1. Сколько запросов в секунду вы сможете отработать Hello World?
Тебе надо — ты и меряй, сюда-то ты чё пришёл?? Не говоря о том, что производительность "виртуальных машин" вообще понятие недетерминированное!
S>2. Добавляем запрос к базе через EF-Core по ключу. Пусть СУБД PostgreSQL. Как изменится скорость выдачи после этого?
Ну, с учётом фазы луны и курса йены, примерно 8234500** запросов в час. Как-то так... точнее надо спрашивать у главного шамана.
Здравствуйте, Kolesiki, Вы писали:
S>>1. Сколько запросов в секунду вы сможете отработать Hello World?
K>Тебе надо — ты и меряй, сюда-то ты чё пришёл?? Не говоря о том, что производительность "виртуальных машин" вообще понятие недетерминированное!
Здравствуйте, Shmj, Вы писали:
S>Есть ли у вас понимание:
Эти цифры не имеют никакой практической ценности, поэтому скорее всего наизусть их будет знать только тот, кто попробовал именно эти конкретные эксперименты.
Hello world например держит 1000 rps, а если добавить select по ключу, то 10 rps. И чё? А у нас почему-то коннекшн пул был отключен, вот включим. Теперь 100 rps. И чё? Увеличим коннекшн пул до максимального размера, который тянет наш инстанс БД. Получится например 300 rps. И чё? Коннекшн пул мы добавили — это не читерство? Может тогда кэш сразу добавить, чтобы в базу не ходить? Получится 999 rps! И чё? — никакого ответа мы не получили, мы просто сидим и тюним какой-то высосанный из пальца синтетический сценарий
Здравствуйте, rosencrantz, Вы писали:
R>Эти цифры не имеют никакой практической ценности, поэтому скорее всего наизусть их будет знать только тот, кто попробовал именно эти конкретные эксперименты.
Для кого не имеют ценности? Если ты за что-то отвечаешь и тебе нужно знать сколько серверов потребуется ПРИМЕРНО — то что ты скажешь? Что не знаю даже примерно, может миллион а может и один сервер справится?
R>Может тогда кэш сразу добавить, чтобы в базу не ходить? Получится 999 rps! И чё?
Кэш поможет если запросы к одним и тем же данным, а это не всегда возможно. По этому нужно представлять насколько скорость упадет без кеша.
R>- никакого ответа мы не получили, мы просто сидим и тюним какой-то высосанный из пальца синтетический сценарий
Запрос к базе — не синтетический сценарий. Даже ваша оценка в 1000 rps — уже о многом скажет в плане количества необходимых серверов для заданной нагрузки. Но у меня получилось 5 тыс. — порядок тот же.
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос.
S>Есть ли у вас понимание:
S>1. Создаем пустой ASP.Net Core сайт, параметры машины примерно как за $100 в мес. по средним тарифам. Сколько запросов в секунду вы сможете отработать Hello World? Примерно это 500, 5000, 50 тыс. или 500 тыс. Есть ли у вас примерное представление или вообще без понятия? https://dotnet.microsoft.com/en-us/
v6.0
dotnet new web -o AppFolder // <= hello
https://nbomber.com/
S>2. Добавляем запрос к базе через EF-Core по ключу. Пусть СУБД PostgreSQL. Как изменится скорость выдачи после этого? https://www.postgresql.org/
S>Ну и т.д. Ориентируетесь ли в этом и насколько?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, rosencrantz, Вы писали:
R>>Эти цифры не имеют никакой практической ценности, поэтому скорее всего наизусть их будет знать только тот, кто попробовал именно эти конкретные эксперименты.
S>Для кого не имеют ценности? Если ты за что-то отвечаешь и тебе нужно знать сколько серверов потребуется ПРИМЕРНО — то что ты скажешь? Что не знаю даже примерно, может миллион а может и один сервер справится?
Вопросы так не задаются и не отвечаются. Если система уже есть, можно проэкстраполировать: 100 юзеров — 1 сервер, 1000 юзеров — 10 серверов. Если системы ещё нет, можно сделать рисёрч проект "на неделю": смоделировать наиболее центральный сценарий, написать вот эти все хелловорлды, написать перф тесты на гатлинге и посмотреть сколько чего куда.
R>>Может тогда кэш сразу добавить, чтобы в базу не ходить? Получится 999 rps! И чё?
S>Кэш поможет если запросы к одним и тем же данным, а это не всегда возможно. По этому нужно представлять насколько скорость упадет без кеша.
Это именно то, что я попытался донести. Я легко вас "разведу" на ещё десяток требований — и от хелло ворлда, с которого вы начали, ничего не останется. Мы придём к очень специфической системе с очень специфическим сценарием использования — вот этот сценарий и нужно дизайнить, измерять и тюнить.
R>>- никакого ответа мы не получили, мы просто сидим и тюним какой-то высосанный из пальца синтетический сценарий
S>Запрос к базе — не синтетический сценарий. Даже ваша оценка в 1000 rps — уже о многом скажет в плане количества необходимых серверов для заданной нагрузки. Но у меня получилось 5 тыс. — порядок тот же.
Один и тот же запрос будет работать по-разному в зависимости от:
1. Клауд провайдера
2. Типа инстанса БД — память, диск (тип, бюджет IO), проц (тип, бюджет computing capacity)
3. Размера БД
4. Продолжительности теста
5. Других запросов
У меня есть какие-то цифры в голове из-за того, что я пару лет баловался с перформанс тестированием (Java/AWS). Самый ценный совет, который я могу дать на основании этого опыта: моделируйте нагрузку, пишите тесты, гоняйте их, смотрите на цифры. С потолка прикидывать, что 1 сервер == 1000 rps — это шаг в сторону астрологии.
Здравствуйте, rosencrantz, Вы писали:
R>Вопросы так не задаются и не отвечаются. Если система уже есть, можно проэкстраполировать: 100 юзеров — 1 сервер, 1000 юзеров — 10 серверов. Если системы ещё нет, можно сделать рисёрч проект "на неделю": смоделировать наиболее центральный сценарий, написать вот эти все хелловорлды, написать перф тесты на гатлинге и посмотреть сколько чего куда.
Вопрос вот в чем: вам приходилось проводить такие измерения для основных случаев? Или же нет и понятия не имеете на что можно рассчитывать?
S>>Кэш поможет если запросы к одним и тем же данным, а это не всегда возможно. По этому нужно представлять насколько скорость упадет без кеша.
R>Это именно то, что я попытался донести. Я легко вас "разведу" на ещё десяток требований — и от хелло ворлда, с которого вы начали, ничего не останется. Мы придём к очень специфической системе с очень специфическим сценарием использования — вот этот сценарий и нужно дизайнить, измерять и тюнить.
Основных случаев не так уж много. Запрос к базе по ключу, запрос к базе по индексу, по нескольким индексам и т.д.
R>Один и тот же запрос будет работать по-разному в зависимости от:
R>1. Клауд провайдера R>2. Типа инстанса БД — память, диск (тип, бюджет IO), проц (тип, бюджет computing capacity) R>3. Размера БД R>4. Продолжительности теста R>5. Других запросов
Да не пытайся размазать и свести понятие истины к несуществующему. Порядок будет один и тот же.
R>У меня есть какие-то цифры в голове из-за того, что я пару лет баловался с перформанс тестированием (Java/AWS). Самый ценный совет, который я могу дать на основании этого опыта: моделируйте нагрузку, пишите тесты, гоняйте их, смотрите на цифры. С потолка прикидывать, что 1 сервер == 1000 rps — это шаг в сторону астрологии.
Примерное понимание должно быть. Хотя бы на уровне порядка.
Здравствуйте, Shmj, Вы писали:
S>Примерное понимание должно быть. Хотя бы на уровне порядка.
Я так понимаю коммерсы хотят оценить затраты?
Дайте наихудший прогноз(предватиеьлно умножив на два), иначе это выглядит как будто нужны результаты производительности реальной, но не существующей системы.
Еще старое правило: скорость эскадры определяется самым тихоходным кораблем.
Здравствуйте, Shmj, Вы писали:
S>Вопрос вот в чем: вам приходилось проводить такие измерения для основных случаев? Или же нет и понятия не имеете на что можно рассчитывать?
Я обычно сообщаю начальству, что систему мы делаем в рассчёте на 2 параллельных пользоваталей, которые пользуются системой раз в месяц, и далее даю начальству возможность начать разговор о нефункциональных требованиях. Обычно начинают накидывать первичные цифры (у нас будет 1млн пользователей), я им в ответ даю всякие вторичные (значит мы говорим про 100,000 запросов в секунду), они удивляются (как же так — чё-то много), и после нескольких (десятков) итераций у нас получается более-менее чёткое понимание сколько чего мы хотим уметь делать (на самом деле 1000 юзеров в первый месяц после запуска, и дальше рост до 10000 за первый год).
S>>>Кэш поможет если запросы к одним и тем же данным, а это не всегда возможно. По этому нужно представлять насколько скорость упадет без кеша.
R>>Это именно то, что я попытался донести. Я легко вас "разведу" на ещё десяток требований — и от хелло ворлда, с которого вы начали, ничего не останется. Мы придём к очень специфической системе с очень специфическим сценарием использования — вот этот сценарий и нужно дизайнить, измерять и тюнить.
S>Основных случаев не так уж много. Запрос к базе по ключу, запрос к базе по индексу, по нескольким индексам и т.д.
В SQL нет такого — "по индексу, по нескольким индексам". Будет индекс использоваться или не будет (и вообще — какой именно индекс) зависит от самого запроса и от статистики в базе. Например в Mysql не тот "order by" легко может привести к тому, что будет использоваться какой-нибудь левый индекс, или вообще весь план выполнения перевернётся вверх ногами. Вот пишете вы select from XXX where aaa = 123 order by bbb — летает. А то же самое, но order by ccc — минуту выполняется. Или ещё веселее: order by bbb — летает, а стоит добавить offset 500 — и сразу тормозит. Или совсем весело: сегодня план быстрый, а через неделю он внезапно меняется и всё тормозит (статистика набралась потому что, и теперь индекс другой используется) — а вы ничего руками не трогали и удивляетесь.
R>>Один и тот же запрос будет работать по-разному в зависимости от:
R>>1. Клауд провайдера R>>2. Типа инстанса БД — память, диск (тип, бюджет IO), проц (тип, бюджет computing capacity) R>>3. Размера БД R>>4. Продолжительности теста R>>5. Других запросов
S>Да не пытайся размазать и свести понятие истины к несуществующему. Порядок будет один и тот же.
Давайте более предметно. Порядок — это сколько?
R>>У меня есть какие-то цифры в голове из-за того, что я пару лет баловался с перформанс тестированием (Java/AWS). Самый ценный совет, который я могу дать на основании этого опыта: моделируйте нагрузку, пишите тесты, гоняйте их, смотрите на цифры. С потолка прикидывать, что 1 сервер == 1000 rps — это шаг в сторону астрологии.
S>Примерное понимание должно быть. Хотя бы на уровне порядка.
В моём последнем софте некоторые методы API отрабатывали за 80 ms, некоторые за 800 ms. Разница в один десятичный порядок. Из этого извлекается какое-то понимание?
Не, вы наверно можете сделать какую-то грубую математику вроде:
1. У веб сервера размер пула потоков для обработки запросов — 200 потоков (это по-моему у Tomcat по умолчанию так)
2. Обработка запроса занимает 1000 мс ("мой здравый смысл" — если дольше, лучше это делать вне контекста запроса API)
Значит мы можем держать нагрузку 200 запросов в секунду на 1 сервере. Т.е. если мы хотим держать 1000 запросов в секунду, нам надо 5 серверов. Много в этом связи с реальностью?
Здравствуйте, rosencrantz, Вы писали:
R>В SQL нет такого — "по индексу, по нескольким индексам". Будет индекс использоваться или не будет (и вообще — какой именно индекс) зависит от самого запроса и от статистики в базе.
При разработке ты сам должен определить какой запрос будет. Выборка по ключу или по индексу отработает примерно ~1000 раз в сек. для любого количества данных.
S>>Да не пытайся размазать и свести понятие истины к несуществующему. Порядок будет один и тот же.
R>Давайте более предметно. Порядок — это сколько?
Нужно понимать почему так.
R>Значит мы можем держать нагрузку 200 запросов в секунду на 1 сервере. Т.е. если мы хотим держать 1000 запросов в секунду, нам надо 5 серверов. Много в этом связи с реальностью?
А в чем связь с реальностью? Увеличить пул потоков?
Не говоря о том, что производительность "виртуальных машин" вообще понятие недетерминированное!
