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

_>>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.
I>Не на реальность, а на синтетику. Это замер обращения к базе через linq. Не забывай смотреть абсолютные цифры — 56 микросекунд на запрос. Типичный http запрос при обработке выполняется на порядки дольше.

Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.

>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.

Ну про цифры мы уже всё выяснили (см. выше)... )))

I>Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.

Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq ). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.

>>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
I>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.

Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.

_>>Так кто там говорил о предельном максимуме расходов в 5%? )
I>Для типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT

О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий? А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )

Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))