Временами SQL являются просто SQL - поскольку он исходит из обернутого соединения ADO.NET и очень мало знает о вызывающей стороне. Чтобы получить подробные сведения об этом (для измерения накладных расходов), оберните интересующий вас код:
using(profiler.Step("Get orders")) {
orders = db.{some query}.ToList();
}
Теперь у вас есть время для единицы кода, и внутри этого времени, времени SQL, которые соответствуют ему. Таким образом, если для кода «Получить заказы» потребовалось 100 мс, а для SQL - 40 мс, значит, у вас есть 60 мс служебных данных.
Что уменьшить накладные расходы:
- попробуйте предварительно скомпилировать запрос
- попробуйте переключиться на
ExecuteQuery<T>
, поэтому равно дерева выражений для разбора
Из опыта, однако, вы, вероятно, обнаружите, что большинство этих накладных расходов происходят из-за "материализации" (то есть превращения строк из базы данных в объекты), особенно в сценарии с высокой пропускной способностью. Мы нашли единственный способ избавиться от этих накладных расходов - использовать dapper-dot-net вместо ExecuteQuery<T>
(у него намеренно похожий API). При этом у нас практически нет накладных расходов между временами «получения заказов» и временами для SQL в этом блоке.