Обновление сайта, тестирование было в порядке, после развертывания, снова хорошо, как только пользовательская нагрузка увеличивается, FAIL?

Question

Мы используем ASP.NET MVC с LINQ to SQL. Мы добавили некоторые функции и протестировали их все до совершенства на нашей QA Box. Мы используем Windows Server 2003 и SQL Server 2005. Поэтому, когда мы выдвигали изменения на веб-сервере Live, мы также использовали Red Gate SQL Compare для внесения новых изменений в базу данных LIVE. Мы снова проверили между несколькими из нас, никаких проблем. Время ложиться спать.

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

Как ни странно, когда все это было вытолкнуто, мы могли затем воспроизвести ошибки в QA, но не раньше, чем все было переведено в LIVE.

Базы данных QA и LIVE находятся на одном и том же SQL Server, но приложения находятся в разных экземплярах Windows Server 2003.

Сгенерировано ошибок:

Индекс находился за пределами массива.

Недопустимая попытка вызвать FieldCount при закрытом считывателе.

Серверу не удалось возобновить транзакцию.

Уже существует открытый DataReader, связанный с этой командой, который должен быть закрыт первым.

Произошла ошибка транспортного уровня при отправке запроса на сервер.

При получении результатов с сервера произошла ошибка транспортного уровня.

Неправильная попытка вызова Read, когда читатель закрыт.

Недопустимая попытка вызова метаданных, когда читатель закрыт.

Счетчик должен быть положительным, а счетчик должен указывать на местоположение в строке / массиве / коллекции. Название параметра: count

ExecuteReader требует открытого и доступного соединения. Текущее состояние соединения - соединение.

Кто-нибудь знает, что, черт возьми, могло произойти?

---

РЕДАКТИРОВАТЬ: Так как мы смогли внезапно повторить ошибки в QA, это не могло быть проблемой загрузки пользователя ... Само собой разумеется, что мы все чувствуем себя действительно испорченными.

Answer 1

Параллелизм всегда приносит ошибки из работы по дереву. Я бы порекомендовал вам проверять объекты, которые могут быть общими для запросов (например, статические члены и синглтоны), и реорганизовывать ваш код таким образом, чтобы обмениваться им было как можно меньше.

Что касается специфики, то для ошибки «Уже есть открытый DataReader, связанный с этой командой, который должен быть сначала закрыт», вы можете попробовать добавить MultipleActiveResultSets = True к строкам подключения.

Answer 2

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

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