Сообщение Re[123]: Тормознутость и кривость linq от 02.07.2016 8:34
Изменено 02.07.2016 8:46 Pauel
Здравствуйте, alex_public, Вы писали:
IT>>Добавил, начало скакать туда сюда, пришлось увеличить количество итераций и нивелировать порядок выполнения. Получилось так:
IT>>
_>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.
Не на реальность, а на синтетику.
> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.
>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты.
_>Так кто там говорил о предельном максимуме расходов в 5%? )
Для типичных сценариев, а не "СУБД на том же компьютере"
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% накладных расходов), причём на достаточно долгих запросах.
Не на реальность, а на синтетику.
> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.
>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты.
_>Так кто там говорил о предельном максимуме расходов в 5%? )
Для типичных сценариев, а не "СУБД на том же компьютере"
Re[123]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
IT>>Добавил, начало скакать туда сюда, пришлось увеличить количество итераций и нивелировать порядок выполнения. Получилось так:
IT>>
_>О, я смотрю это уже становится похоже на реальность (уже 16% накладных расходов), причём на достаточно долгих запросах.
Не на реальность, а на синтетику. Это замер обращения к базе через linq. Не забывай смотреть абсолютные цифры — 56 микросекунд на запрос. Типичный http запрос при обработке выполняется на порядки дольше.
> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
Если ты влупишь СУБД рядом с сервером, то они будут мешать друг другу только самим присутствием — каждому нужны память и кеш процессора. В типичном приложении СУБД обслуживает несколько серверов.
>то скорее всего получим в точности результаты liiw (с 90% накладных расходов). Я уже молчу что будет в случае весьма распространённого в вебе запроса одиночной строки по индексу (например пользователя по id сессии)...
В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Так кто там говорил о предельном максимуме расходов в 5%? )
Для типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
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