Добавление большего количества аппаратного v / s-рефакторинга кода за время

Question

Справочная информация: Корпоративное приложение - очень будет написано для своего времени в 2004 году.

Stack: .NET, интенсивное использование удаленного взаимодействия, веб-службы в стиле ASMX, SQL Server

Проблема: Приложение позволяет пользователю просматривать различные мастера из-за отсутствия лучшего термина, все их действия хранятся в том, что мы называем «состояние wiz», которое, по сути, представляет собой XML, который очень часто сохраняется в базе данных сервера SQL, потому что мы позволяем пользователям приостановить / возобновить их применение. Часто в этих мастерах XML-код, содержащий состояние мастера, становится очень большим, я говорю о 5-8 МБ данных, и мы заметили, что, когда у нас внезапный поток одновременных пользователей, мы начали получать случайные тайм-ауты для базы данных, потому что многое из того, из чего состоит состояние волшебника, - это отслеживание коллекций «вещей». Иногда эти пользовательские коллекции становятся очень большими.

Вопрос: Сегодня мы были на собрании, и мы ожидаем, что в октябре начнется бурная деятельность, которая протестирует систему, как никогда раньше, и, возможно, приведет к огромным состояниям мастера, которые возвращаются с веб-сервера в базу данных и обратно. Суть ситуации в том, что существует только одна база данных и один веб-сервер.

В качестве аргументов, из-за сложности приложения, скажем, о добавлении любого вида кластеризации / зеркалирования для увеличения пропускной способности базы данных не может быть и речи. Я выступил на собрании и сказал, что самым быстрым способом решения этой проблемы в кратчайшие сроки будет добавление большего количества серверов в интерфейсное веб-приложение, чтобы нагрузка могла быть распределена между веб-серверами. Руководитель разработки сказал, что я совершенно не прав, и это не будет иметь никакого эффекта, потому что у нас есть только одна база данных, поэтому добавление большего количества веб-ресурсов ничего не даст. У него есть один из других разработчиков, чтобы уменьшить количество раздувания XML, которое мы часто сохраняем в базе данных. Вероятно, в долгосрочной перспективе уменьшение размера xml, который мы передаем туда и обратно, является правильной идеей, но добавление дополнительных веб-серверов действительно не даст никакого эффекта, я просто думаю, что с точки зрения одновременных пользователей, это должно Помогите.

Любые ответы приветствуются, доказательство того, что большее количество веб-серверов поможет, будет чистой победой.

Спасибо.

РЕДАКТИРОВАТЬ : Мы используем двоичную сериализацию для хранения XML в базе данных в поле изображения.

Answer 1

Никто, похоже, не предложил этого, как насчет замены сериализации XML вашего мастера на JsonSerialization.

Мало того, что это даст вам небольшой прирост производительности в самой сериализации, так как DataContractSerializer (быстрее) и Newtonsoft Json.NET (быстрее всего) выполняют XML-сериализаторы в .NET. Это должно легко уменьшить размер графа вашего объекта на 50% и более (в зависимости от количества свойств по сравнению с большими строками в XML).

Это должно значительно снизить количество операций ввода-вывода, которые применяются к серверу Sql. Это также должно ограничить объем области, необходимой для значительного изменения вашего приложения (при условии, что оно хорошо спроектировано и работает через обычные вызовы для сериализации / десериализации).

Если вы решите пойти по этому пути, также потратьте время на сравнение BSON с JSON, так как я думаю, что вполне вероятно, что двоично-закодированный предложит еще большую экономию пространства (и дальнейшее сокращение ввода-вывода) из-за размера ваших объектных графов.

Answer 2

Я ничего не слышал о поиске "узких мест". Разве это не первое, что нужно сделать? Вот метод, который я использую. В противном случае вы просто вкладываете в догадки. Это не сработает.

Я был на подобных встречах, где все взволнованы, разбрасывая идеи, и «руководство» хочет принимать «решения», но слепой ведет слепого. Наклонитесь и выясните что происходит. Вы не можете делать это на собраниях.

Некоторое время назад я смотрел на проблему с производительностью, похожую на вашу. Самым большим «узким местом» было написание и анализ XML с выделением, настройкой и уничтожением сопутствующей памяти. Тогда были и другие. Вы можете найти то же самое или что-то другое.

P.S. Я продолжаю цитировать «узкое место», потому что все проблемы с производительностью, которые я обнаружил, были совсем не похожи на горлышки бутылок. Скорее они похожи на чрезмерно густые деревья вызовов, которые нуждаются в радикальном сокращении, такие как создание и чтение гор XML без всякой уважительной причины.

Answer 3

Если узким местом является база данных, то больше веб-сервисов вам мало помогут.

Проблема может заключаться в том, что проблема заключается не только в размере данных, но и в количестве одновременных запросов к одной и той же таблице. Количество записей будет большой проблемой. Если ваша запись XML находится в транзакции с другими запросами, вы можете попытаться отделить запись XML от этой транзакции, чтобы сократить время блокировки таблицы XML.

Как сказано в vdeych, вы можете попробовать сжатие, чтобы уменьшить размер данных. (Это увеличит нагрузку на веб-серверы.)

Вы также можете попробовать кэшировать данные. Читайте с сервера SQL, только если данные еще не находятся в кэше. Убедитесь, что вы не обновляете сервер SQL, если ваши данные не изменились.

Answer 4

Если скорость записи данных в SQL является узким местом, более быстрая подача данных в SQL не должна иметь никакого эффекта.

Я не совсем уверен, какова структура данных, но, возможно, сжатие данных XML на веб-серверах перед записью может иметь положительный эффект.

Answer 5

Майк на месте, без понимания содержания ресурса, приводящего к проблемам с производительностью, никакие обсуждения не решат проблему.Я добавлю, что тайм-ауты сокетов, которые влияют на выполняющиеся операторы, являются симптомом и никогда не навязываются SQL Server, а являются артефактом конфигурации вашего драйвера или брандмауэра или подобного устройства между приложением и базой данных, навязывающими их (если вы не говоритео тайм-аутах для новых соединений, то у вас есть хост в серьезном стрессе под нагрузкой).

Учитывая, что ваш симптом является тайм-аутом базы данных, вам нужно начать с него.Если они указывают на длительные операторы, которые приводят к тайм-ауту сокета, используйте профилировщик SQL Server для захвата рабочей нагрузки при одновременном мониторинге системных ресурсов.Учитывая, что это зрелое приложение и тип рабочей нагрузки, о котором вы упомянули, вряд ли это связано с настройкой операторов, возможно, оно сводится к ограничению ресурсов Процессор, память или емкость дискового ввода-вывода

Это руководство Technet является очень хорошим местом дляначало: http://technet.microsoft.com/en-us/library/cc966540.aspx

Если это конфликт ресурсов, то это простое обсуждение того, как конфликт ресурсов может быть настроен, настроен или решен путем добавления большего количества всего, что нужно.

Редактировать:Я должен добавить, что, учитывая проблему с производительностью базы данных, большее количество серверов приложений может усугубить проблему, поскольку вы увеличиваете количество параллелизма, которое в противном случае может контролироваться пулом соединений, обработкой запросов или другими ограничениями.

Answer 6

Я не эксперт по .NET, но, возможно, использование двоичной сериализации увеличит пропускную способность.Убедиться, что XML не хранится в виде текста (довольно очевидно, но я подумал, что упомяну это).Кроме того, реляционные базы данных лучше всего подходят для хранения реляционных данных, поэтому, возможно, замена слоя ORM вместо сериализации (возможно, звучит) может ускорить процесс.