Счетчик просмотров страниц - настройка базы данных и техника / стратегия

Question

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

Используя рекомендации, я разработал httpHandler, который будет обрабатывать запрос всякий раз, когда он срабатывает:

<link rel="stylesheet" href="cn.axd?t=1&id=232" type="text/css" />

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

2. Лучшим вариантом было бы внедрение асинхронной очереди, в которой информация регистрируется в очереди MS и в конечном итоге регистрируется в базе данных через (Политика исключений)

3. Было бы медленнее проверять, существует ли определенная запись (PageID) и увеличивать счетчик или вставлять запись в базу данных и агрегировать позже, когда это необходимо. Нам просто нужно запустить агрегацию в конце недели, чтобы увидеть общее количество просмотров страниц за конкретную страницу за неделю.

Спасибо всем.

Answer 1

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

Какой бы метод вы ни внедрили, я рекомендую следующее:

1. Делать вставки постоянно (они быстрее обновлений).
2. Делайте их асинхронными, чтобы не блокировать основной поток и не блокировать будущие запросы.
3. Иметь ночной процесс, который суммирует данные и очищает таблицу в пункте 1.
4. Делайте ваш выбор по суммированным данным.

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

Answer 2

интересных вопросов! Как и многие другие вопросы о настройке производительности, есть некоторые компромиссы.

1. Возможно. Лучше было бы загрузить этот обработчик внутри IMG href = "", установив размеры 0, чтобы он был невидим для пользователя.

2. При большой нагрузке это было бы предпочтительным, чтобы ваш обработчик мог вернуться сразу после постановки в очередь. Однако для большинства нагрузок, вероятно, столь же быстро выполнить простой запрос T-SQL для увеличения счетчика.

3. Лучше всего было бы добавить +1 к значению непосредственно в вашем запросе T-SQL, "count = count + 1" и т. Д. Это быстро выполнится и приведет к последующему поиску ваших данных без агрегация.

Надеюсь, это поможет!

Адам

Answer 3

Разработка MQ только для отслеживания просмотров страниц / показов звучит немного сложнее.

Если вас беспокоит какая-либо задержка, воспринимаемая пользователем, почему бы просто не запустить запрос XmlHttpRequest в JavaScript на ваш URL? Это будет обрабатываться асинхронно.

Answer 4

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

Ссылка на обработчик как стиль CSS не должна сильно останавливать время загрузки, но это может иметь некоторый эффект.

С помощью простого скрипта вставки / обновления я не могу себе представить, что затраты производительности при выполнении оператора стоили бы попытаться создать систему в стиле очереди ...