Сообщение Re[59]: Тормознутость и кривость linq от 11.04.2016 6:39
Изменено 11.04.2016 7:20 Serginio1
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
S>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались)
S>>Для подавляющего количества сайтов это запредельная нагрузка.
_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Кроме того
Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis
Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
S>>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
_>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте.
Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же.
В 1С эта схема прекрасно работает.
_>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
S>> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
_>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Хранимые процедуры можно применять и в Linq, в том числе на CLR
_>Здравствуйте, Serginio1, Вы писали:
_>>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
S>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались)
S>>Для подавляющего количества сайтов это запредельная нагрузка.
_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Кроме того
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
•6 миллионов посещений в месяц
•86% трафика приходит с Google
•9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis
Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
S>>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
_>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте.
Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же.
В 1С эта схема прекрасно работает.
_>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
S>> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
_>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Хранимые процедуры можно применять и в Linq, в том числе на CLR
Re[59]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
S>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались)
S>>Для подавляющего количества сайтов это запредельная нагрузка.
_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Кроме того
Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis
Плюс наверняка используется SignalR для пуш нотификации
Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
S>>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
_>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте.
Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же.
В 1С эта схема прекрасно работает.
_>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
S>> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
_>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Хранимые процедуры можно применять и в Linq, в том числе на CLR
_>Здравствуйте, Serginio1, Вы писали:
_>>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
S>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались)
S>>Для подавляющего количества сайтов это запредельная нагрузка.
_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Кроме того
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
•6 миллионов посещений в месяц
•86% трафика приходит с Google
•9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis
Плюс наверняка используется SignalR для пуш нотификации
Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
S>>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
_>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте.
Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же.
В 1С эта схема прекрасно работает.
_>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
S>> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
_>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Хранимые процедуры можно применять и в Linq, в том числе на CLR