Сообщение Re[125]: Тормознутость и кривость linq от 08.07.2016 5:37
Изменено 08.07.2016 5:49 Pauel
Здравствуйте, alex_public, Вы писали:
_>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.
Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
>>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
_>Ну про цифры мы уже всё выяснили (см. выше)... )))
Да, мы выяснили, что ты по прежнему отказываешься даже признавать наличие самого веб-стека.
_>Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq
). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.
То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?
I>>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.
Я про абсолютное время запроса. Именно оно определяет, какая будет загрузка процессора, потому как количество юзеров каким было, таким и осталось.
>типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
_>О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий?
А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )
Типичный в вебе, типичный в энтерпрайзе, типичный в высоконагруженых — это все очень, очень разное.
Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.
_>Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))
Не в курсе. Пудозреваею, rsdn большей частью висит в ожидании ответа от бд.
_>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.
Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
>>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
_>Ну про цифры мы уже всё выяснили (см. выше)... )))
Да, мы выяснили, что ты по прежнему отказываешься даже признавать наличие самого веб-стека.
_>Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq
). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?
I>>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.
Я про абсолютное время запроса. Именно оно определяет, какая будет загрузка процессора, потому как количество юзеров каким было, таким и осталось.
>типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
_>О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий?
А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )Типичный в вебе, типичный в энтерпрайзе, типичный в высоконагруженых — это все очень, очень разное.
Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.
_>Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))
Не в курсе. Пудозреваею, rsdn большей частью висит в ожидании ответа от бд.
Re[125]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
_>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.
Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
>>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
_>Ну про цифры мы уже всё выяснили (см. выше)... )))
Да, мы выяснили, что ты по прежнему отказываешься даже признавать наличие самого веб-стека.
_>Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq ). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.
То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?
I>>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.
Я про абсолютное время запроса к бд (на фоне веб-стека). Именно оно определяет, какая будет загрузка системы, потому как количество юзеров каким было, таким и осталось. Стек как работал, так и работает. linq здесь минорный игрок.
>типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
_>О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий? А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )
Типичный в вебе, типичный в энтерпрайзе, типичный в высоконагруженых — это все очень, очень разное.
Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.
_>Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))
Не в курсе. Пудозреваею, rsdn большей частью висит в ожидании ответа от бд.
_>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.
Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
>>> Теперь если ещё сделать быстрые запросы (например сделав тест с СУБД на том же компьютере),
I>>СУБД на том же компьютере это комп разработчика ? Абсолютные цифры посмотри. В конфигурациях, где СУБД на том же компьютере, никогда в реале не будет такого количества запросов.
_>Ну про цифры мы уже всё выяснили (см. выше)... )))
Да, мы выяснили, что ты по прежнему отказываешься даже признавать наличие самого веб-стека.
_>Мешать они конечно же будут, но только в том случае, если приложение будет каким-то кривым (например использующим Linq
). А нормальное приложение, у которого основная задача в конвертации json в sql (мгновенное дело, если не привлекать какой-нибудь там Linq ) и потом результатов снова в json (ну может ещё какая-нибудь аутентификация по кукам в начале), будет большую часть времени банально висеть в ожидание результата из БД.То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?
I>>В приложениях, где выгребают пользователей по id и СУБД на том же компьютере, никогда не будет той нагрузки, которая выявит эти проценты. Более того, на фоне http хандлера уже разницы почти не будет.
_>Бредим? ) Процент накладных расходов не зависит от абсолютного значения нагрузки. О высоконагруженных приложениях тут говорят только потому, что для них это становится уже критично (слишком дорого по деньгам). А проявляется то оно абсолютно везде, просто в большинстве случаев этот факт не принципиален, т.к. требуемое железо адекватно по деньгам.
Я про абсолютное время запроса к бд (на фоне веб-стека). Именно оно определяет, какая будет загрузка системы, потому как количество юзеров каким было, таким и осталось. Стек как работал, так и работает. linq здесь минорный игрок.
>типичных сценариев, а не "СУБД на том же компьютере", и замеры end-2-end, а не в синтетике, как показал IT
_>О, т.е. теперь ситуация, когда http-демон и БД находятся на одном сервере, — это у нас не типичный сценарий?
А как ты думаешь, какой процент веб'а работает по такому сценарию, а какой с разделёнными машинами? )Типичный в вебе, типичный в энтерпрайзе, типичный в высоконагруженых — это все очень, очень разное.
Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.
_>Кстати, а вот скажем сайт rsdn по твоему на скольких машинах работает? )))
Не в курсе. Пудозреваею, rsdn большей частью висит в ожидании ответа от бд.