Выполнение запроса в Page Load - плохая идея?

Question

Я запускаю приложение ASP.NET, в котором я добавил запрос вставки / обновления в [global] Page_Load. Таким образом, каждый раз, когда пользователь просматривает какую-либо страницу на сайте, он обновляет базу данных в соответствии со своей активностью (идентификатор сеанса, время, страница, на которую он пришел) Я еще не реализовал это, но это было единственное предложение, которое мне было дано относительно того, как отслеживать, сколько людей в настоящее время находится на моем сайте.

Это убьет мою базу данных и / или IIS в долгосрочной перспективе? Мы полагаем, что в среднем на сайте одновременно находится от 30000 до 50000 пользователей. Я не могу постоянно блокировать свой сайт из-за попадания в базу данных при каждом посещении страницы для каждого пользователя. Я обеспокоен тем, что это произойдет, однако я впервые пытаюсь найти решение, подобное этому, поэтому я могу быть просто параноиком.

Answer 1

Конструкции на основе вставок имеют меньшую блокировку, чем конструкции на основе обновлений.

Таким образом, если пользователь вошел в систему, а затем вышел из нее, в дизайне на основе вставки у вас будет несколько строк с SessionID в каждой, по одной для каждого действия, тогда как в дизайне на основе обновлений у вас будет SessionId , LoginTime и столбец LogoutTime, и вы должны обновить LogoutTime на основе SessionId.

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

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

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

Answer 2

Сделай это асинхронно.

Создайте dll, которая обрабатывает обновление, а при загрузке страницы сделайте пожар и забудьте с параметрами.

Answer 3

Чтобы отслеживать, сколько пользователей в настоящее время на вашем сайте, вы можете использовать счетчики производительности. То, что вы описываете, звучит как полноценная регистрация каждого попадания на страницу.

Допустим, вы действительно подключили 50 тыс. Пользователей одновременно.

Пока у вас нет разногласий между обновлениями (попытка заблокировать одну и ту же запись), база данных может отслеживать очень большое количество вставок и обновлений. Вы должны сделать некоторое планирование мощности, чтобы гарантировать, что груз может быть перенесен. 50 тыс. Пользователей, посещающих страницу каждую минуту, дадут вам 50 тыс. Вставок и 50 тыс. Обновлений в минуту, примерно 850 вставок и 850 обновлений в секунду, которые необходимо зафиксировать (очистить журнал). Поддерживает ли подсистема ввода-вывода вашей БД такую ​​нагрузку при записи, помимо ответа на все запросы (чтения)?

Кроме того, 50 000 пользователей, выполняющих 1 посещение страницы в минуту, добавляют до 72 миллионов обращений в день, 72 миллиона. регистрируя вставки, с такой скоростью вам нужно тщательно спланировать размер базы данных и подумать, какой анализ вы будете выполнять на собранных данных, так как запрос 2 миллиардов строк (данных за один месяц) не даст вам быстрых результатов. (на самом деле ... довольно медленно).

Выполнение этого асинхронно может дать вам некоторое облегчение при очень коротких шипах, но не в долгосрочной перспективе. Если ваша система БД не может справиться с нагрузкой, то выполнение асинхронных вызовов просто создаст очередь невыполненных работ в процессе приложения (в пуле приложений ASP), и это будет расти до нехватки памяти, и в этот момент все бдительные IIS будут «перезагружать» пул приложений, что приводит к потере всех ожидающих асинхронных обновлений.

Answer 4

Как прямой ответ на ваш вопрос, да, выполнение запроса к базе данных в потоке с каждым запросом - плохая идея:

1. Синхронные запросы свяжут поток, что уменьшит вашу масштабируемость (меньше одновременных действий)
2. Вставки (или обновления) БД - это записи в БД, которые будут загружать ваш лог-том
3. Доступ к БД не требуется для сценария с одним сервером / одним AppPool

Я ответил на ваш вопрос о том, как считать пользователей в другой теме:

Лучший способ отслеживать текущих онлайн-пользователей

Если вы работаете в среде с несколькими серверами / с балансировкой нагрузки, то в действительности может потребоваться доступ к БД. В этом случае:

1. Поставить их в очередь в фоновый поток, чтобы поток запросов переднего плана не должен был ждать
2. Использование регулятора ресурсов в SQL 2008 для уменьшения конкуренции за доступ к другим БД
3. Соберите несколько обновлений / вставок вместе в одну партию за одну транзакцию, чтобы минимизировать давление ввода-вывода диска журнала
4. Возвращает текущий счетчик при каждом доступе к БД, чтобы свести к минимуму повторные обращения

На случай, если это будет интересно, я подробно расскажу о проблемах с синхронизацией / асинхронной потоковой обработкой и описанных выше методах в своей книге вместе с примерами кода: Сверхбыстрый ASP.NET .

Answer 5

Я вообще не являюсь парнем из ASP, но что делать, вместо того, чтобы регистрировать всю эту другую информацию и вставлять свой IP-адрес?

Если у них уже есть IP-адрес, есть отметка времени last_seen, и при каждом обновлении просто удаляйте все строки, которые не были 10 минут назад?

Вот как бы я сделал снимок. Это намного более экономно, но я не уверен в том, чтобы проверять и удалять так много на таком высококлассном сайте.

Answer 6

Как насчет добавления небольшого объекта в сеанс?

Что-то вроде LoggedInUserFlag: IDisposable

В конструкторе увеличивайте свой счетчик, однако вы решили его реализовать.

Затем в методе Dispose уменьшите счетчик.

Таким образом, независимо от того, как завершится сеанс, счетчик всегда будет (со временем) уменьшаться.

см

http://weblogs.asp.net/cnagel/archive/2005/01/23/359037.aspx

для получения информации об использовании IDisposable.

Answer 7

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

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

Answer 8

Что не так с журналами IIS?

2009-05-01 12:30:31 207.219.27.35 GET /assocadmin/ibb-reg.asp - usernameremoved 544.566.570.575 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0;+SLCC1;+.NET+CLR+2.0.50727;+Media+Center+PC+5.0;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30618) 200 0 0 40058

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

Answer 9

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

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

РЕДАКТИРОВАТЬ: конец сессии не всегда срабатывает. Я бы предложил вызвать оператор обновления / хранимую процедуру в другом событии начала сеанса (в дополнение к другому оператору вставки), который исправит недействительные сеансы.

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