Влияние многих (!) Небольших запросов

Question

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

По существу, приложение использует объектно-реляционный картограф для извлечения данных, но делает это очень неэффективно / неправильно. По сути, он выполняет серию выборок графа сущностей для заполнения сетки данных в пользовательском интерфейсе, а при привязке данных к сетке (это ASP.Net Webforms) выполняет дополнительные выборки, которые ведут к другим выборкам и т. Д.

Чистый эффект этого состоит в том, что выполняется множество крошечных запросов. Использование SQL Profiler показывает, что определенная страница выполняет более 10 000 запросов (для заполнения одной сетки. Ни один запрос не выполняется более 10 мс, и большинство из них регистрируется как 0 мс в Profiler. Каждый запрос использует и освобождает одно соединение, а также серию запросы будут однопоточными (на HTTP-запрос).

Я очень хорошо знаком с ORM и точно знаю, как решить проблему.

Мой вопрос: каков точный эффект от того, что в приложении выполняется много-много небольших запросов? Каким образом это / может ли это подчеркнуть различные компоненты системы?

Например, как это влияет на процессор и память веб-сервера? Это затопит пул соединений и вызовет блокировку? Как это повлияет на память сервера базы данных, процессор и ввод-вывод?

Я ищу относительно общие ответы, главным образом потому, что я хочу начать мониторинг областей, которые, вероятно, будут наиболее затронуты (мне нужно измерить => исправить => повторно измерить). Максимальное количество одновременных пользователей системы может составить около 100-200 пользователей.

Answer 1

Это будет зависеть от базы данных, но обычно для каждого запроса существует фаза разбора. Если в запросе использовались переменные связывания, он, вероятно, будет кэширован. Если нет, вы носите удар синтаксического анализа, и это часто означает короткие блокировки ресурсов. то есть ПЛОХО. В Oracle центральный процессор и блокировка гораздо более распространены, чем исполняемые. SQL Server меньше, но хуже при выполнении. Очевидно, что делать 10К чего-либо по сети будет ужасным решением, особенно для 200 пользователей. Громкость, я уверен, в порядке, но эта частота действительно высветит все накладные расходы в задержке связи и тому подобное. Пулы соединений, как правило, исчисляются сотнями, а не десятками тысяч, и теперь у вас есть десятки тысяч объектов, которые все создаются, ставятся в очередь, управляются, уничтожаются, собирают мусор и т.д.

Но я уверен, что вы уже знаете все это в глубине души. Отключите ORM для этой части и напишите хранимую процедуру для выполнения одного запроса, чтобы вернуть ваш набор результатов. Затем положите его на сетку.