Как минимизировать нагрузку на сервер для чата на ASP.NET MVC с SignalR?

Question

[zanooda]

Есть игровой чат на ASP.NET MVC с использованием SignalR. Есть БД с диалогами, репликами и пользователями (AspNet.Identity). Есть четыре конроллера (BaseController который наследуется от Controller и в котором создаётся контекст диалогов и реплик, стандартный AccountController который наследуется от BaseController, HomeController который наследуется от BaseController и VerseController который тоже наследуется от BaseController) и сигналар хаб в котором тоже нужно создать инстанс базы данных что бы записывать в неё новые реплики не перезагружая страничку.

Если я не ошибаюсь (а я могу, запросто) то каждый раз когда пользователь открывает сайт, на сервере создаётся инстанс контроллера в котором создаётся контекст и запускается функция которая обрабатывает контекст и выдёт его в View. То есть если тысяча пользователей одновременно пользуются чатом то на сервере тысяча раз создаётся инстанс БД. Я бы хотел что бы во время пользования чатом на сервере инсианс БД создавался только один раз. Вопрос где? WCF? Web API? Только в SignalR хабе? Как лучше всего сделать что бы минимизировать нагрузку на сервер и что бы у большого кол-ва пользователей чат работал быстро и без задержек?

Answer 1

[Даша Циклаури]

Не инстанс контекста, а не самой БД - разные вещи!
Используй dependencyInjection и переиспользуй инстанс контекста БД в каждом последующем контроллере, подойдет NInject.
Где хостится сервер? IIS? Katana? Если IIS, то стоит помнить про то, что пул может убиваться, соответственно объекты не вечные, в отличие от self-hosted.

Чтобы минимизировать нагрузку и не завязываться на БД стоит продумать кэш в оперативной памяти, продумать сценарии рефреша страницы и подгрузки недавней истории. И, конечно же, корректно использовать entity для чтения (Не трэкать всё подряд) и записи (вставка пачками - bulkinsert по таймеру, если требуется ну очень много вставок).

Comments

[Dmitry Pavlov]

Согласен. Желательно кстати проверить сколько инстансов контекста БД создается по факту - залогируйте ради инстереса или подебажьте.

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

[Даша Циклаури]

Dmitry Pavlov: 1 инстанс EF - плохо, считай параллельные запросы теряем, using - тоже плохо по памяти и скорости, можно на чтение 1 инстанс, несколько на запись (переиспользуемые, с диспозом после 100 записей скажем), но это всё очень внимательно надо кодить

[Dmitry Pavlov]

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

Answer 2

[eRKa]

У меня точно такой же вопрос стоит уже вторую неделю, только в другом контексте. Мониторинг GPS трекеров. Есть серверная часть, которая по UDP протоколу получает сообщение от трекера и которая так же имеет доступ к БД, чтоб понять кому принадлежит трекер, затем сообщение уходит на хаб SignalR для отсылки веб-клиенту. Получается что у меня два конекшина к базе, от сервера с сайтом (ASP.NET MVC) и от сервера с хабом. И тоже думаю как сделать одно соединение, чтоб базу меньше напрягать, и тоже кручусь вокруг WCF или Web API.