Здравствуйте, Serginio1, Вы писали:
S> Давай посчитаем сколько из всего этого затрат составляет Linq. Так как кроме запросов есть еще данные сессии, формирование страниц
Сессия — да, +1 запрос к базе на чтение, +1 на обновление (если это в SQL, в чём очень сомневаюсь. хотя, если речь о самом начальном решении, и такое возможно). Данные короткие.
Формирование страниц — страница отдаётся набором параметров для скрипта клиентскому браузеру, дальше он формирует все видимые элементы.
S>нотификация типа SignalR
Если мы про версию 2009-2010, по-моему, её там не было — надо было перегружать страницу за новыми веяниями.
S> Ты считаешь только запросы. Еще раз нужно держать данные о сессиях которые миллионы, есть необходимость о Пуш нотификациях? затраты на формирование страниц, итд. Может оказаться, что затраты на Linq это вообще малая доля процента.
Ещё раз — мы обсуждаем версию 7-летней давности, а не современную, в которой перед ним туева гора проксеров и отдельных хранилищ.
S>>> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента. S>>> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. N>>Чуть в сторону от исходного вопроса — а разве импортозамещение не предполагает уход от MS? S> У 1С есть Вэб клиент и работа с PostgreSQL. А скорость 1С заметно медленнее .Net
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Serginio1, Вы писали:
S>> Давай посчитаем сколько из всего этого затрат составляет Linq. Так как кроме запросов есть еще данные сессии, формирование страниц
N>Сессия — да, +1 запрос к базе на чтение, +1 на обновление (если это в SQL, в чём очень сомневаюсь. хотя, если речь о самом начальном решении, и такое возможно). Данные короткие. N>Формирование страниц — страница отдаётся набором параметров для скрипта клиентскому браузеру, дальше он формирует все видимые элементы.
Еще раз ты считаешь, что основная нагрузка это запросы SQL. Страница может быть статической, а данные обновляться через AJAX, либо формироватся полностью страницы на сервере. Это как раз затраты больше, чем отображение SQL запроса, на типизированные данные Linq.
S>>нотификация типа SignalR
N>Если мы про версию 2009-2010, по-моему, её там не было — надо было перегружать страницу за новыми веяниями.
Ну вот тебе и еще нагрузка на сервер
S>> Ты считаешь только запросы. Еще раз нужно держать данные о сессиях которые миллионы, есть необходимость о Пуш нотификациях? затраты на формирование страниц, итд. Может оказаться, что затраты на Linq это вообще малая доля процента.
N>Ещё раз — мы обсуждаем версию 7-летней давности, а не современную, в которой перед ним туева гора проксеров и отдельных хранилищ.
Я тебе как раз привел данные 7 летней давности. А современная нагрузка на SO на порядок выше.
S>>>> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента. S>>>> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. N>>>Чуть в сторону от исходного вопроса — а разве импортозамещение не предполагает уход от MS? S>> У 1С есть Вэб клиент и работа с PostgreSQL. А скорость 1С заметно медленнее .Net
N>А веб-сервер на чём сделан?
Да. Есть в том числе реализация Вэб, HTTP сервисов, ODATA.
Там движок написан на С++, но он является интерпритатором, сейчас они смотрят в сторону Java для конфигуратора.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... ))) S> Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике. S>Кроме того S>
S>3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
S>•6 миллионов посещений в месяц
S>•86% трафика приходит с Google
S>•9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
S> Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis S>Плюс наверняка используется SignalR для пуш нотификации S>Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
Я и не сказал, что вся их оптимизация (там же на пару порядков вышло похоже) заключалась только в выкидывание linq2sql. Это был один из многих пунктов их программы оптимизации. И только в сумме они смогли дать такой существенный эффект. Однако устранение любого из этих пунктов существенно ухудшило бы производительность и заставило покупать горы дополнительного железа.
_>>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах. S> Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте. S>Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же. S>В 1С эта схема прекрасно работает.
Какая милая теория. ))) Если бы она ещё была верной, то как хорошо жилось бы. Не появилось бы вообще таких понятий как кластер (для вертикального) и nosql (для горизонтального)...
_>>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер). S> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
Так зависит от архитектуры. Тому же СО понадобилось бы сейчас несколько сотен, если бы они остались на старой кривой. ))) А так справляются сейчас вполне разумным железом.
S> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
У нас полно вполне себе взрослых ERP систем отечественного производства (всякие там Галактики, Компасы и т.п.), которые пытаются конкурировать с иностранными SAP R/3, Microsoft Dynamics и т.п. И это всё явно другой уровень, в котором 1C просто нечего делать. Не потому что плохая, а потому что другое предназначение.
_>>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше. S> Хранимые процедуры можно применять и в Linq, в том числе на CLR
Здравствуйте, Ikemefula, Вы писали:
_>>Кстати, если глянуть страничку этой библиотеки (https://github.com/StackExchange/dapper-dot-net), то можно увидеть много любопытных замеров быстродействия. Из которых сразу понятна ориентация этой библиотечки и что там думают про linq1sql и т.п. ))) I>Недавно мы обсуждали замеры производительности. Ты не забыл ? Так вот фокус в том, что linq2db работает быстрее чем dapper.
Но вообще это достаточно справедливый текст, который опять же является частным случаем моей более общей мысли: в рамках C# у нас нет оптимального инструмента. Есть или приятное и тормознутое или быстрое, но не очень удобное. Чтобы получить оптимум надо отбросить саму платформу. )
Здравствуйте, alex_public, Вы писали:
_>>>Кстати, если глянуть страничку этой библиотеки (https://github.com/StackExchange/dapper-dot-net), то можно увидеть много любопытных замеров быстродействия. Из которых сразу понятна ориентация этой библиотечки и что там думают про linq1sql и т.п. ))) I>>Недавно мы обсуждали замеры производительности. Ты не забыл ? Так вот фокус в том, что linq2db работает быстрее чем dapper.
_>Это где ты такое взял? )
Linq это та самая статическая типизация, за которую ты тут выступаешь: "intellisense, compile-time type checking and compile-time syntax checking combine to make you more productive and to catch errors earlier."
_>Но вообще это достаточно справедливый текст, который опять же является частным случаем моей более общей мысли: в рамках C# у нас нет оптимального инструмента. Есть или приятное и тормознутое или быстрое, но не очень удобное. Чтобы получить оптимум надо отбросить саму платформу. )
Да, тебе мешает платформа, поскольку ты хочешь выжимать биты просто так, ради крутости. Ты заметь, везде ты упоминаешь про EF или linq2sql, и тебе почему то нравится игнорировать linq2db
Здравствуйте, alex_public, Вы писали:
S>> Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте. S>>Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же. S>>В 1С эта схема прекрасно работает.
_>Какая милая теория. ))) Если бы она ещё была верной, то как хорошо жилось бы. Не появилось бы вообще таких понятий как кластер (для вертикального) и nosql (для горизонтального)...
Она работает. Всё о чем ты говоришь это 0.00000...1% _>>>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер). S>> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
_>Так зависит от архитектуры. Тому же СО понадобилось бы сейчас несколько сотен, если бы они остались на старой кривой. ))) А так справляются сейчас вполне разумным железом.
Сейчас и сервера уже другие.
S>> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
_>У нас полно вполне себе взрослых ERP систем отечественного производства (всякие там Галактики, Компасы и т.п.), которые пытаются конкурировать с иностранными SAP R/3, Microsoft Dynamics и т.п. И это всё явно другой уровень, в котором 1C просто нечего делать. Не потому что плохая, а потому что другое предназначение.
Угу. При этом прекрасно конкурирует. Люди после 1С перейдя на SAP R/3, Microsoft Dynamics плюются со страшной силой. http://v8.1c.ru/erp/
Мало того, 1С быстро дорабатывает конфигурации род изменение законодательства. Сейчас добавили возможно расширять конфигурации http://курсы-по-1с.рф/news/what-new-in-1c-platform-8-3-7/
.1c.ru/rus/partners/ckp-v8_top500.jsp]500 самых масштабных проектов системы программ «1С:Предприятие 8» по числу автоматизированных рабочих мест (АРМ), подтвержденных письмами клиентов: [/url]
13510 — ТРАНСМАШХОЛДИНГ (внедрение в группе компаний)
◦ 10000 — ООО "Межрегионгаз"
◦ 8629 — ООО "Башкирэнерго" (внедрение в группе компаний)
◦ 8132 — ФГУП "Почта России" (внедрение в группе компаний)
◦ 7865 — ОАО "КАМАЗ" (внедрение в группе компаний)
◦ 3500 — ООО "Сибур — Центр обслуживания бизнеса"
◦ 3500 — ООО «СИБУР–Центр Обслуживания Бизнеса»
◦ 3500 — ООО "Ителла"
◦ 3500 — ООО "СИБУР — Центр Обслуживания Бизнеса"
◦ 3090 — ОАО "Иркутскэнерго" (внедрение в группе компаний)
◦ 3080 — ООО "Сибур-Центр обслуживания Бизнеса"
◦ 3080 — ООО «СИБУР-Центр обслуживания бизнеса»
◦ 2800 — АО «АЭМ-технологии»
◦ 2500 — Банк Газпромбанк (АО)
◦ 2500 — ОАО "ТГК-1"
◦ 2000 — ОАО "КАМАЗ"
◦ 2000 — АО "АЭМ-технологии"
◦ 1800 — ОАО "ЕВРАЗ Металл Инпром" (ЕМИ)
_>>>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше. S>> Хранимые процедуры можно применять и в Linq, в том числе на CLR
_>Можно. ) Но не нужно (см. пример тех же SO).
А где написано, что ХП не используют CLR (.Net)?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>>>Недавно мы обсуждали замеры производительности. Ты не забыл ? Так вот фокус в том, что linq2db работает быстрее чем dapper. _>>Это где ты такое взял? ) I>rsdn I>Но вообще можно попробовать спросить здесь https://github.com/sdanyliv/ormbattle
http://ormbattle.net — "Домен ormbattle.net выставлен на продажу!". Угу, авторитетно. ) Да и на гитхабе тоже сразу видны все графики и таблицы измерений. ))) В общем я "поверил", да. )))
_>>Угу, особенно пункт 4 умиляет. ))) I>Linq это та самая статическая типизация, за которую ты тут выступаешь: "intellisense, compile-time type checking and compile-time syntax checking combine to make you more productive and to catch errors earlier."
Да я не об этом. Просто забавно у них вышло. Что-то вроде:
Статья "почему не надо использовать не linq решения".
Пункт 4. Потому что вы любите linq.
I>Да, тебе мешает платформа, поскольку ты хочешь выжимать биты просто так, ради крутости. Ты заметь, везде ты упоминаешь про EF или linq2sql, и тебе почему то нравится игнорировать linq2db
Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение. linq2sql всплыло из разговора о stackoverflow, т.к. оно у них когда-то там было, пока не выкинули. Ну а linq2db мы тоже здесь разбирали, как самого быстрого представителя этого направления (но всё равно намного медленнее голых sql строк).
_>Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение. linq2sql всплыло из разговора о stackoverflow, т.к. оно у них когда-то там было, пока не выкинули. Ну а linq2db мы тоже здесь разбирали, как самого быстрого представителя этого направления (но всё равно намного медленнее голых sql строк).
Там шло сравнение не выполнения запроса, а отображения данных запроса на типизированные данные.
И разница между заполнения linq2db и ручная десериализация 7%. 12000 раз тебе повторю. Запросы могут кэшироваться как автоматом так и в ручную. Для Linq to EF не было отключена проверка кэша. NoTrackig().
Я тебе предлагаю, взять и написать тесты и выявить тонкие места. А linq2sql это вобще первая реализация.
Пока все твои слова голословны.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Хранимые процедуры можно применять и в Linq, в том числе на CLR _>>Можно. ) Но не нужно (см. пример тех же SO). S> А где написано, что ХП не используют CLR (.Net)?
Здравствуйте, alex_public, Вы писали:
I>>Но вообще можно попробовать спросить здесь https://github.com/sdanyliv/ormbattle
_>http://ormbattle.net — "Домен ormbattle.net выставлен на продажу!". Угу, авторитетно. ) Да и на гитхабе тоже сразу видны все графики и таблицы измерений. ))) В общем я "поверил", да. )))
А почему автор репы должен оплачивать домен ?
Смотри даты коммитов, делай выводы. Не хочешь мерять — спроси хозяина репы. Но ты ведь чисто понамекать сюда пришел, правильно ?
I>>Да, тебе мешает платформа, поскольку ты хочешь выжимать биты просто так, ради крутости. Ты заметь, везде ты упоминаешь про EF или linq2sql, и тебе почему то нравится игнорировать linq2db
_>Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение.
Ты не видишь разницы между ORM и micro-ORM и EF. Это всё три разных инструмента, прежде всего.
Здравствуйте, Ikemefula, Вы писали:
_>>Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение. I>Ты не видишь разницы между ORM и micro-ORM и EF. Это всё три разных инструмента, прежде всего.
Потому что в варианте использования с linq они все тормозят! Вот в варианте работы через голые sql строки некоторые из них (sql2db, dapper — у него это вроде единственный режим) уже работают нормально, а некоторые (EF) умудряются тормозить и в таком случае. )))
Здравствуйте, alex_public, Вы писали: _>Что-то ты бредишь) Библиотеки в любом случае компилируются где-то, один раз. А линкуются динамически или статически — это уже по вкусу разработчиков. Мне больше нравится статическое решение, т.к. с ним меньше проблем при распространение.
А ещё все твои мета-трюки с превращением linq-запроса в склейку строк на C++ возможны только при подстановке исходников-в-исходники.
Если один драйвер хочет заменять .take(1000) на "top 1000", а другой — на "limit 0, 1000", то для "склейки строк" придётся эти драйвера описывать в виде шаблонов, поставлять в исходниках, и компилировать статически.
А если захочется как в С# — подменять драйвер в уже скомпилированном и развёрнутом приложении ппри помощи строки в конфиге — то придётся отказаться от шаблонов и склейки строк, а заниматься полноценным анализом expression trees в рантайме. Со сравнимой, ессно, производительностью.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Я — могу. Так же как и любой, знакомый с языком SQL. ))) Ну а для неосиливших SQL действительно стоит поискать другие инструменты. )
Речь идёт не о том, что кто-то конкретный врукопашную неспособен соптимизировать SQL.
А о том, что можно декомпозировать задачу. В одном месте — определить функцию типа getAllOrders, которая возвращает все заказы, видимые текущему пользователю (...where acl.UserID = @currentUser), а в других местах (нескольких) ей пользоваться.
При этом в одном месте будут выводиться все детали ордера, а в другом — только подсчитываться общее количество.
И в результирующем sql не будет ничего лишнего — никаких join, не участвующих в выборке, никаких полей, не попавших в финальную проекцию.
В плохом случае вообще эти части проекта компилируются раздельно — потому что их пишут разные команды.
И никто вам не даст возможности руками выполнить инлайнинг и подпатчить SQL.
В совсем плохом случае возможность дадут, а вот денег на то, чтобы руками выписать оптимальный SQL для всех 128 вариантов сочетаний — не дадут. И неосилившим linq придётся поискать другую работу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>>>Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение. I>>Ты не видишь разницы между ORM и micro-ORM и EF. Это всё три разных инструмента, прежде всего.
_>Потому что в варианте использования с linq они все тормозят!
Относительно чего тормозят, mov ax, bx ?
У тебя замеры чисто синтетические, без учета реального кеширования и тд.
>Вот в варианте работы через голые sql строки некоторые из них (sql2db, dapper — у него это вроде единственный режим) уже работают нормально, а некоторые (EF) умудряются тормозить и в таком случае. )))
Ты продолжаешь сравнивать Камаз с жигулями. Цитирую:
замеры "у нас тут голый sql" vs "ORM c прикрученым change tracking" говорят скорее о квалификации кричащих
Здравствуйте, alex_public, Вы писали:
I>>А в третьей может расставить хинты, где какой алгоритм джойна использовать, или вообще заменить джойн скажем на cte, если это даёт профит в частном случае.
_>Заканчивай с теорией и переходи к конкретным реальным примерам. Хотя бы к одному. )
Вот, из последнего, с чем столкнулся. Каждая из трех строчек лидирует по производительности в зависимости от базы
select count(x) from ... таблица
select count(1) from ... 1 или *
select count(id) from ... праймари кей
Если твоя мулька генерит разных код в зависимости от базы, все в порядке, она умеет оптимизировать. А если нет, то запрос придется переписывать под разные базы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>>> Хранимые процедуры можно применять и в Linq, в том числе на CLR _>>>Можно. ) Но не нужно (см. пример тех же SO). S>> А где написано, что ХП не используют CLR (.Net)?
_>Перечитай внимательно цитату в этом http://rsdn.ru/forum/flame.comp/6412784.1
Здравствуйте, Ikemefula, Вы писали:
I>Вот, из последнего, с чем столкнулся. Каждая из трех строчек лидирует по производительности в зависимости от базы I>
I>select count(x) from ... таблица
I>select count(1) from ... 1 или *
I>
Это два разных запроса, выдающих два разных результата.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Я всех их упоминал. Вообще с одной стороны пинать EF — это приблизительно как издеваться на инвалидом. Но с другой стороны этот инвалид является главным официальным инструментом платформы и соответственно имеет максимальное распространение. I>>Ты не видишь разницы между ORM и micro-ORM и EF. Это всё три разных инструмента, прежде всего.
_>Потому что в варианте использования с linq они все тормозят! Вот в варианте работы через голые sql строки некоторые из них (sql2db, dapper — у него это вроде единственный режим) уже работают нормально, а некоторые (EF) умудряются тормозить и в таком случае. )))
У меня стойкое ощущение дежа-вю.
Ты все тоже самое говорил год назад, и два года назад, может и три года назад, но я уже не помню.
Тормоза Linq существуют в очень высоконагруженных системах, и в головах некоторых людей.
Причем в нагруженных системах легко эти тормоза обойти за счет компиляции запросов, а в головах людей эта проблема нерешаемая.
И что-то мне кажется что у тебя нет высоконагруженных систем как класса, ты их даже в глаза не видел.
Здравствуйте, _ABC_, Вы писали:
I>>Вот, из последнего, с чем столкнулся. Каждая из трех строчек лидирует по производительности в зависимости от базы I>>
I>>select count(x) from ... таблица
I>>select count(1) from ... 1 или *
I>>
_AB>Это два разных запроса, выдающих два разных результата.
У меня нет под рукой точных запросов. Все три выдают один и тот же результат, разница только в быстродействии.
Здравствуйте, Ikemefula, Вы писали:
I>У меня нет под рукой точных запросов. Все три выдают один и тот же результат, разница только в быстродействии.
Если диалект SQL реализует ANSI-совместимый COUNT, то второй вариант вернет число всех записей из набора данных (таблицы),
а первый только те, у которых x is not null.
Т.е., для a(x), содержащего следующие значения (null, null, null, 1, 2, 3), count(x) вернет 3, а count(*) вернет 6.
