Проектирование одновременных запросов к базе данных - PullRequest
2 голосов
/ 17 августа 2010

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

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

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

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

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

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

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

1 Ответ

0 голосов
/ 17 августа 2010

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

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

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

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

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

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

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

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

...