Как реализовать надежный счетчик веб-страницы?
Вот как это работает, используя GitHub на компьютере с Windows. Допустим, у вас есть клонированный репозиторий в C:\dir1. Структура каталогов выглядит следующим образом: C:\dir1\dir2\dir3. Каталог dir3 - это каталог, в котором я хочу стать новым отдельным репо.
Github:
- Создайте свой новый репозиторий:
MyTeam/mynewrepo
Bash Prompt:
-
$ cd c:/Dir1 -
$ git filter-branch --prune-empty --subdirectory-filter dir2/dir3 HEAD
Возвращено:Ref 'refs/heads/master' was rewritten(fyi: dir2 / dir3 чувствительно к регистру.) -
$ git remote add some_name git@github.com:MyTeam/mynewrepo.git
git remote add origin etc. не сработало, вернул "remote origin already exists" -
$ git push --progress some_name master
4 ответа
Я немного поигрался с этим, основываясь на комментариях здесь. Что я придумал, так это подсчет счетчика в простом поле. В моем приложении у меня есть объекты фрагмента кода со свойством Views.
Когда фрагмент просматривается, метод отфильтровывает (белый список) только то, что, как мы надеемся, должно быть браузерами:
public bool LogSnippetView(string snippetId, string ipAddress, string userAgent)
{
if (string.IsNullOrEmpty(userAgent))
return false;
userAgent = userAgent.ToLower();
if (!(userAgent.Contains("mozilla") || !userAgent.StartsWith("safari") ||
!userAgent.StartsWith("blackberry") || !userAgent.StartsWith("t-mobile") ||
!userAgent.StartsWith("htc") || !userAgent.StartsWith("opera")))
return false;
this.Context.LogSnippetClick(snippetId, IpAddress);
}
Затем хранимая процедура использует отдельную таблицу для временного хранения последние просмотры, в которых хранится идентификатор фрагмента, введенная дата и IP-адрес. Каждое представление регистрируется, и когда появляется новое представление, оно проверяется, обращался ли тот же IP-адрес к этому сниппету в течение последних 2 минут. если это так, то ничего не регистрируется.
Если это новое представление, то представление регистрируется (снова SnippetId, IP, Entered), а фактическое поле Views обновляется в таблице Snippets.
Если это ' s это не новое представление, таблица очищается с любыми зарегистрированными представлениями, которые старше 4 минут. Это должно привести к минимальному количеству записей в таблице журнала просмотра в любое время.
Вот сохраненная процедура:
ALTER PROCEDURE [dbo].[LogSnippetClick]
-- Add the parameters for the stored procedure here
@SnippetId AS VARCHAR(MAX),
@IpAddress AS VARCHAR(MAX)
AS
BEGIN
SET NOCOUNT ON;
-- check if don't allow updating if this ip address has already
-- clicked on this snippet in the last 2 minutes
select Id from SnippetClicks
WHERE snippetId = @SnippetId AND ipaddress = @IpAddress AND
DATEDIFF(minute, Entered, GETDATE() ) < 2
IF @@ROWCOUNT = 0
BEGIN
INSERT INTO SnippetClicks
(SnippetId,IpAddress,Entered) VALUES
(@SnippetId,@IpAddress,GETDATE())
UPDATE CodeSnippets SET VIEWS = VIEWS + 1
WHERE id = @SnippetId
END
ELSE
BEGIN
-- clean up
DELETE FROM SnippetClicks WHERE DATEDIFF(minute,Entered,GETDATE()) > 4
END
END
Кажется, это работает довольно хорошо. Как отмечали другие, это не идеально, но похоже, что при первоначальном тестировании этого достаточно.
На вашем месте я бы отказался от точности моего счетчика. Каждое решение (например, файлы cookie, IP-адреса и т. Д.), Как вы сказали, имеет тенденцию быть ненадежным. Итак, я думаю, что лучше всего использовать избыточность в вашей системе: используйте файлы cookie, «Flash-cookie» (общие объекты), IP-адреса (возможно, в сочетании с пользовательскими агентами) и идентификаторы пользователей для людей, которые вошли в систему.
Вы могли бы реализовать какую-то схему, в которой любому неизвестному клиенту дается уникальный идентификатор, который сохраняется (надеюсь) на клиентской машине и повторно передается с каждым запросом. Затем вы можете привязать IP-адрес, пользовательский агент и / или идентификатор пользователя (плюс все, что вы можете придумать) к каждому уникальному идентификатору и наоборот. Отметка времени и уникальный идентификатор каждого щелчка могут быть зарегистрированы где-нибудь в таблице базы данных, и каждый щелчок (по крайней мере, каждый щелчок на вашем веб-сайте) может быть пропущен или отклонен в зависимости от того, насколько недавно был последний щелчок для того же уникального идентификатора. Это, вероятно, достаточно надежно для краткосрочных всплесков кликов, а в долгосрочной - в любом случае не будет иметь большого значения (для проблемы с кликами, а не для счетчика страниц).
Дружественные роботы должны иметь соответствующий пользовательский агент и может быть проверен по списку известных пользовательских агентов роботов (я нашел один здесь после простого поиска в Google), чтобы его правильно идентифицировать и обрабатывать отдельно от реальных людей.
Используйте IP-адреса вместе с сеансами. Считайте каждую новую сессию для IP-адреса как одно попадание в счетчик. Вы можете сохранить эти данные в базе данных журналов, если считаете, что вам когда-нибудь понадобится их просмотреть. Это может быть полезно для расчета, когда ваш сайт получает больше всего трафика, сколько трафика в день, на каждый IP-адрес и т. Д.
Если вы используете PHP, вы можете использовать сеансы для отслеживания активности определенных пользователей. В сочетании с базой данных вы можете отслеживать активность с определенных IP-адресов, которые, как вы можете предположить, принадлежат одному и тому же пользователю.
Используйте временные метки, чтобы ограничить количество обращений (например, предположим, что не более одного обращения за 5 секунд), и чтобы сообщить при новых "посещениях" сайта (например, если последнее обращение было более 10 минут назад).
Вы можете найти свойства $ _SERVER [], которые помогут вам определить ботов или тенденции посетителей (например, использование браузера) .
править: Я отслеживал обращения и посещения раньше, считая просмотр страницы за попадание и +1 к посещениям при создании нового сеанса. Он был довольно надежным (более чем достаточно надежным для тех целей, для которых я его использовал. Браузеры, которые не поддерживают файлы cookie (и, следовательно, не поддерживают сеансы), и пользователи, которые отключают сеансы, в настоящее время довольно редки, поэтому я бы не беспокоился об этом, если нет причин быть чрезмерно точными.