Проецирование одновременных запросов к базе данных

Question

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

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

Вопрос, который я задал от людей инфраструктуры, - «сколько одновременных пользователей». Давайте не будем обсуждать обоснование поиска только этой фигуры; это то, о чем просили в этом случае!

Это веб-интерфейс, сервер SQL Server с довольно фиксированной, легко поддающейся количественной оценке аудиторией. Для того, чтобы закрепить это вплоть до реальных одновременных запросов в очень грубой манере, как я вижу, это сводится к более гранулированным единицам измерений:

1. Общей аудитория
2. одновременных сеансы
3. одновременных запросы
4. Синхронные запросы БД

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

Это, по общему признанию, очень простой, и я уверен, что там есть более подробное руководство. Если кто-то может поделиться своим подходом к этому упражнению или указать мне на другие ресурсы, которые могли бы сделать процесс немного менее ad hoc, это было бы здорово!

Answer 1

Я попробую, но, очевидно, не зная подробностей, довольно сложно дать точный совет.

Прежде всего, ребята инфраструктуры могли бы задал этот вопрос от лицензирования перспективном (сервер SQL может быть лицензированы для каждого пользователя или на процессор)

Теперь вернемся к вашему вопросу. «Общая аудитория» важна, если вы можете предсказать/разработать этот номер. Это может привести к худшему сценарию, когда все пользователи сразу попадают в базу данных (например, 9 утра, когда каждый входит в систему).

Если вы храните информацию о сеансе, у вас, вероятно, будет как минимум 2 подключения на одного пользователя (1 сеанс + 1 базовая БД). Но это число может (иногда заметно) уменьшаться пулом соединений (зависит от того, как вы подключаетесь к базе данных). Используйте сценарий наихудшего случая - 50 системных соединений + 2 * количество пользователей.

Одновременные запросы/запросы зависят от характера приложения. Нужна более подробная информация. Более одновременные запросы (к вашему интерфейсу) не обязательно будут переводить на большее количество запросов на задней панели.

Сказав все это - для целей калькуляции вам необходимо сосредоточиться на увеличенной картине.

1. Лицензия сервера SQL (если моя память мне подходит) будет стоить ~ 128 тыс. AUD (двойной Xeon). Горячий/теплый режим ожидания? Двойная стоимость.

2. Диск-хранилище - сколько у вас будет памяти? Диски относительно дешевы, но если вы собираетесь использовать SAN, стоимость может стать заметной. Кроме того, чем больше дисков, тем лучше с точки зрения производительности.