Здравствуйте, alex_public, Вы писали:

IT>>Добавил, начало скакать туда сюда, пришлось увеличить количество итераций и нивелировать порядок выполнения. Получилось так:
IT>>

IT>>LINQ: 1000000 in 00:00:56.0547832
IT>>ADO:  1000000 in 00:00:49.1683344
IT>>SQL:  1000000 in 00:00:48.4624714
IT>>

_>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.

Не на реальность, а на синтетику. Это замер обращения к базе через linq. Не забывай смотреть абсолютные цифры — 56 микросекунд на запрос. Типичный http запрос при обработке выполняется на порядки дольше.

> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),

СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.

>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...

В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.

_>Так кто там говорил о предельном максимуме расходов в 5%? )

Для типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT