ASP.NET + Entity Framework — обработка периодических всплесков трафика

У меня есть приложение MVC и WebAPI, которому необходимо регистрировать действия, выполняемые пользователями, в моей базе данных. Это почти всегда одна вставка в таблицу, которая имеет менее 5 столбцов (т. е. очень мало данных передается по сети). Интерфейс данных, который я сейчас использую, — Entity Framework 6.

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

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

Существуют ли хорошие решения для ASP.NET MVC для буферизации входящих данных запроса, а затем пакетной вставки их в базу данных каждые несколько секунд?

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


c# asp.net entity-framework web-traffic
person joe_coolish    schedule 11.09.2015    source источник
comment
Почему-то я думаю, это похоже на отслеживание аналитики (события и т. д.), поэтому мой мозг движется в этом направлении - что-то мешает подходу на стороне клиента? Собирать данные и сохранять их на клиенте до тех пор, пока вы не определите время для пакетной обработки? Что-то вроде очереди сообщений бедного (wo)man/s :) Или, если подумать, это похоже на корзину для покупок на стороне клиента (добавляйте, удаляйте, очищайте по мере необходимости).   -  person EdSF    schedule 12.09.2015

Ответы (1)


arrow_upward
2
arrow_downward

Когда трафик резко возрастает, некоторые из моих клиентов получают ошибки тайм-аута, потому что страница не завершает загрузку до тех пор, пока сервер не вставит данные в базу данных.

Я бы предложил использовать очередь сообщений. Пусть код рендеринга веб-сайта просто отправляет объект в очередь, представляющую действие, а отдельный процесс (например, служба Windows) считывает из очереди и записывает в базу данных с помощью Entity Framework.

ОБНОВЛЕНИЕ

В качестве альтернативы вы можете регистрировать доступ к файлу (быстро) и иметь отдельный процесс для чтения файла и записи информации в вашу базу данных.

Я предпочитаю вариант с очередью сообщений, но он добавляет еще одну часть архитектуры.

person Eric J.    schedule 11.09.2015
comment
Какая очередь сообщений? MSMQ — это технология, с которой я не совсем знаком, поэтому, если есть другая служба очередей, работающая поверх IIS (или Server 2012 R2, если уж на то пошло), мне было бы очень интересно узнать о ней. Кстати, у меня есть несколько серверов в веб-ферме, поэтому, если это может быть без сохранения состояния, это было бы идеально для моей установки. я добавлю это к моему вопросу - person joe_coolish; 11.09.2015
comment
Примечание. Если вы согласны с тем, что время от времени теряется часть журнала действий пользователя, вы можете использовать отдельный поток и что-то вроде BlockingCollection(), а не очередь сообщений. Необработанные данные будут потеряны, когда домен приложения перезапустит stackoverflow.com/questions/10852515/ - person Eric J.; 12.09.2015
comment
На самом деле я переместил большие объемы транзакционных данных из SQL в Redis. В этих данных мало или совсем нет связи, поэтому я смог довольно быстро все переписать. Потребовалось гораздо больше размышлений, чтобы ввести данные, но, черт возьми, это быстро! - person joe_coolish; 08.11.2015