Насколько хорошо .NET масштабируется?
(Я начну с того, что поясню, что я не разработчик .NET и не привязан к какой-либо другой среде.)
Недавно я услышал, что Лондонская фондовая биржа обрушилась на целый день. Я также слышал, что программное обеспечение было написано на .NET. До этого момента в загруженные дни их производительность снижалась. Кажется, люди обвиняют .NET.
Я не хочу обсуждать эту историю, но она напомнила о том, как масштабируется .NET? Насколько велико для .NET?
Ответы 16
К сожалению, существует так много других проблем, которые могут привести к ухудшению проекта по мере его масштабирования, что вам придется многое преодолеть, прежде чем вы сможете обвинить фреймворк. И если вы не сможете увидеть и тщательно проанализировать исходный код, будет трудно сказать, в чем была основная причина. Готов поспорить, что это была не структура.
И нет, я не работаю с .NET каждый день.
Почему у .NET были какие-то ограничения по размеру, которых не было бы на других платформах? Я не могу представить себе ситуацию, когда вы станете «слишком большим» для .NET. Однако вам действительно следует указать, говорите ли вы о приложении .NET winforms или ASP.NET, а также о других соответствующих факторах. Этот вопрос слишком расплывчатый, чтобы дать подробный ответ.
Кстати, то, что вас зовут Dr Unix, подразумевает некоторую предвзятость.
Тот факт, что его зовут «Dr Unix», должен означать, если вообще что-либо, что он хорошо разбирается в Unix, но трудно думать, что это подразумевает какое-либо предубеждение за или против .NET. Только мои 2 цента.
Вопрос Dr.UNix о масштабируемости .NET, приводящий отрицательный пример, является необъективным. Как бы ты это ни выразился, Брайан.
Многие крупные сайты, такие как Мое пространство, Dell.com, работают на asp.net. Также обратите внимание на этот Статья MSDN, который дает хорошую точку зрения экспертов.
Если все сделано правильно, архитектура перекладывает большинство переходных состояний на клиента, что упрощает кластеризацию и делает ее на удивление масштабируемой. Таким образом, в этот момент это проблема Системы в целом, а не ASP.NET.
Мои 2 цента.
Что ж, я думаю, что этот сайт находится на платформе .net. На нем также построены сайты Microsoft. Поэтому я думаю, что если все будет сделано правильно, то сайт .net будет масштабироваться. Посмотрите некоторые комментарии Джеффа об этом сайте, и их проблемы, как правило, связаны с ошибками кодирования или проблемами архитектуры.
Честно говоря, я думаю, что все сводится к оптимизации кода, помимо инфраструктуры.
В Подкаст StackOverflow 19 Джефф рассказал о том, как им пришлось настроить SQL Server для обработки нагрузок, которые имеет StackOverflow; обратите внимание, что здесь требовалась не настройка .NET.
Также следует отметить, что MySpace.com, одна из самых массовых социальных сетей, работает на ASP.NET..
Использование MySpace только ASP.NET свидетельствует о его масштабируемости. Все сводится к тому, как разработчики будут писать свои приложения таким образом, чтобы максимально использовать эту возможность.
@RichB, я использую MySpace только ради трафика, и ничего больше: p Принеси немного сиропа от кашля!
Да, StackOverflow написан на C# / .NET и является очень успешным примером крупномасштабного сайта.
Возможно, именно объем транзакций обрушил биржу.
Хотя многие примеры, приведенные до сих пор, хороши, это всего лишь крупные веб-сайты. (Вы ненавидите меня за то, что я говорю «просто»). Они раздают пользователям страницы и случайные приложения (например, скребковые). Фондовая биржа обрабатывает покупки / продажи и сопоставляет покупателей / продавцов. Это на несколько порядков больше работы для серверов приложений.
Я видел, как базы данных падают.
MySpace заставляет людей быстро добавлять и читать в течение всего дня. Это не просто приложение для обслуживания страниц и скрабов.
Что ж, .NET хорошо подходит для сред HTP. Причина, по которой произошел сбой обмена, не должна быть связана с .NET ... скорее с архитектурой. Однако, насколько мне известно, архитектура основана на обмене сообщениями, поэтому она должна хорошо масштабироваться при добавлении дополнительных узлов.
Dot Net хорошо масштабируется. У нас есть кластеры серверов, на которых запущен сервер IIS, а также веб-сайты и приложения asp.net, и когда наша пользовательская нагрузка увеличивается, мы можем добавлять серверы (легко) для увеличения емкости. Это происходит во время определенных событий, и масштабируемость архитектуры .net нас не подвела.
Я бы рискнул предположить (как и другие), что это не проблема .net.
Вот вам большая толстая книга по этой теме:
Повышение производительности и масштабируемости приложений .NET (Microsoft Press)
Это действительно хорошая книга. Его надо преподавать в университете.
Вы можете написать плохой код, который не масштабируется ни на одном языке.
.Net вполне может масштабироваться до любого размера системы, но, как и в случае с любым другим технологическим стеком, вы должны строить систему с учетом масштабирования.
LSE упала в худший из возможных дней, но по какой бы то ни было причине я сомневаюсь, что проблема заключалась в основном стеке. Я подозреваю, что это случай, когда плохие рабочие обвиняют свои инструменты.
На самом деле простои на LSE не имели абсолютно никакого отношения к торговой платформе .NET:
The LSE said the system had been hit by a "connectivity issue" and insisted that the problem did not lie with its flagship TradElect trading platform.
http://www.itworld.com/networking/54760/london-stock-exchange-trading-stops-network-fails
Так кто-то буквально за провод дернул? В этом случае любая технология «потерпела бы неудачу».
Все сводится к трем вещам:
- Насколько хорошо спланировано приложение
- Какова была первоначальная масштабная цель человека, который ее построил
- Постоянные работы в ямах для улучшения и масштабирования решения.
MySpace упоминался ранее, это известный факт, что они переписывали свое приложение несколько раз, когда переходили на новый шаг масштабирования (количество пользователей / просмотров страниц и т. д.). Если бы они решили создать последнюю версию для начала, это было бы слишком дорого в обслуживании и было бы нерентабельно - масштабируемость должна основываться на текущем положении и следующей цели масштабирования.
И последнее: хотя его часто считают уклончивым, надежное стресс-тестирование может дать вам хорошее представление о том, как ваше приложение справляется с нагрузкой, к которой вы стремитесь, до того, как ваши пользователи испытают это и случится катастрофа.
Как говорили другие, дело не в платформе.
Важна архитектура вашего приложения - балансировка нагрузки, управление состоянием, секционирование и т. д. Они не зависят от платформы.
Меня действительно беспокоит, когда люди говорят, что .NET - это предпочтительная платформа, потому что она «масштабируема», она не более или менее масштабируема, чем любая другая платформа: PHP, ColdFusion, JSP или собственные скомпилированные приложения с C++ / Delphi и т. д. Это особенность фреймворка, это особенность дизайна приложения.
MySpace, конечно, не сторонник масштабируемости, вместо этого посмотрите на технологию, лежащую в основе поиска Google, или на проект SETI @ home.
На самом деле .NET - моя наименее любимая платформа для работы, потому что она зашла слишком далеко в попытках упростить программное обеспечение, настолько, что есть вещи, которые я хочу сделать, а она не может, и поэтому попытки преодолеть ограничения .NET тратят время где это было бы легко и быстро сделать с помощью C++ или PHP. .NET для разработки программного обеспечения - это то же самое, что duplo bricks для машиностроения - ни один уважающий себя инженер-механик не захочет ограничиваться квадратными блоками шириной в дюйм.
Если приложение должно быть масштабируемым, вам нужно подумать о том, какие данные должны быть разделены между серверами, и какие минимальные данные необходимы для того, чтобы приложение работало и служило своей цели. Необходимости масштабирования приложения часто можно избежать, имея в первую очередь сверхэффективный код (например, не .NET или Java), но для этого обычно требуется базовое понимание сборки, по крайней мере, и того, как выбранный вами язык переводится на машину. код.
Я несколько не согласен с тем, что масштабируемость является особенностью фреймворка, а не особенностью дизайна приложения. Скомпилированный язык будет лучше масштабироваться (ну, по крайней мере, использовать меньше ресурсов), чем язык сценариев, такой как PHP. Ruby сейчас очень популярен, но также имеет некоторые проблемы с масштабируемостью потенциал, поскольку он однопоточный. Я уверен, что меня заинтересует этот вопрос, потому что, конечно, есть способы справиться с этим.
Инфраструктура может предоставлять функции, позволяющие разрабатывать масштабируемые приложения, или может опускать такие функции и препятствовать разработке таких приложений.
Я думаю, вы обнаружите, что PHP (несмотря на то, что он написан в сценариях) может превзойти ASP.NET в достижении того же результата, потому что ASP.NET имеет очень дорогие накладные расходы на создание серверной DOM для каждой отображаемой страницы. Трудно найти объективные тесты, поэтому я могу только предложить вам проверить их на себе на предмет веских доказательств - я это сделал. Не поймите меня неправильно, я всегда предпочитаю C++ для повышения производительности, PHP имеет свое место, и .NET тоже. Дело в том, что многие люди защищают .NET из ложных убеждений; что .NET более масштабируема или более производительна, чем что-либо еще.
Я запустил относительно большой сайт asp.net и обнаружил, что он отлично масштабируется. Конечно, большую часть этого я приписываю наличию отличных инструментов для диагностики и исправления узких мест в коде. Рискну предположить, что проблемы с кодированием вызывают 99,99% проблем, которые возникают у людей во фреймворке любой.
Позже новости ...
«TradElect, технология торговой платформы группы, которая должна быть заменена в конце этого года программным обеспечением, разработанным MillenniumIT, шри-ланкийским поставщиком технологий, принадлежащим LSE». ...
http://www.efinancialnews.com/story/2010-09-13/ex-lse-tech-chief-joins-green-investment-company
«Эта сделка позволяет Группе реализовать новые, более гибкие, инновационные и эффективные ИТ-возможности для будущего развития нашего бизнеса, а также запустить новую платформу для торговли наличными, которая обеспечит значительно меньшую задержку, значительно более высокую пропускную способность и улучшенную масштабируемость». ...
Я недавно разговаривал с компанией ... они перешли на Java, но не из-за недостаточной масштабируемости .NET, а в большей степени из-за чрезмерной масштабируемости ... лицензионных сборов. Этому небольшому стартапу нужно было потратить более миллиона долларов, чтобы не добиться единой точки отказа для своего критически важного приложения. :(