Реализация функциональности “пользователь он или офф-лайн”
На коммуникационных сервисах, таких как сайты знакомств, форумы, социальные сети, очень удобно, когда рядом с ником показывается значок символизирующий на сайте пользователь (онлайн) или нет (оффлайн).
Самый простой способ, это в базе данных в таблицу пользователей ввести специальное поле с временем последней активности. Его надо обновлять при каждом просмотре страницы этим пользователем или по таймеру через ajax. Однако уже при нескольких сотнях пользователей онлайн это выливается в повышенную нагрузку на базу данных постоянными апдейтами и селектами этой таблицы. Плюс это мешает кешированию страниц, так как запросы к базе все равно делать прийдется.
Сегодня нашел оригинальное решение, которое позволяет обойти эти проблемы. Данные о том в онлайне ли пользователь мы будем хранить в мемкеше с небольшим временем жизни (чуть больше времени таймера), а обновлять также при каждом просмотре страницы или по таймеру. Если данные есть, то пользователь на сайте, если возвращено false, то пользователь уже ушел. Работы с памятью намного быстрее чем с базой данных, да и кешировать данные теперь можно.
P.S. Жаль ушел с хабрахабра... интересно было бы пообсуждать эту мысль.
Ещё по теме:
Написано Сентябрь 12, 2007
Комментарии
Илья Рабченок - сентября 13, 2007 01:28
Денис, ты юзабилити занимаешься?
тут социальная сеть на поруху )
Денис Болтиков - сентября 13, 2007 01:36
Я занимаюсь всем кроме дизайна :) и SEO по высокочастотникам ))
Денис Радченко - сентября 13, 2007 02:02
Хорошая идея.
lusever - сентября 13, 2007 04:21
Идея интересная.
Но когда нужно поле last_visit оно берется из тойже таблички что и имя пользователя, которое все равно выбирается. В лучшем случае можно сэкономить на апдейтах, если они не отложенные.
Maxim - сентября 13, 2007 08:05
Денис, а можно по-подробнее? Что за мемкеш?
Денис Болтиков - сентября 13, 2007 08:16
2lusever
Да, думал об этом. Пока никаких оригинальных идей нет.
2Maxim
Можно, сегодня вечером напишу пост про это.
Денис Болтиков - сентября 13, 2007 13:04
2lusever
Подумал. Данные из поля last_visit, именно как данные, нужны только при выводе профиля пользователя. В остальных случая оно используется только чтобы посчитать онлайн пользователь или нет, а этом мы уже меняем на работу с мемкешем. Поэтому это поле можно смело вынести в отдельную таблицу и спокойно его апдейтить. Этим мы разгрузим таблицу users.
lusever - сентября 13, 2007 17:00
Мы берем поле с датой в то же время когда берем имя пользователя, а одно (десять) дополнительных полей нагрузку не делают. Может стоит поискать применение этой идее в более нужных местах? Например, количество онлайн?
Денис Болтиков - сентября 13, 2007 17:07
2lusever
а) Мы можем вообще не брать имя пользователя, потому что контент страницы лежат в кеше или закеширован sql запрос. А статус присутствия на сайте показывать реальный.
б) Если в таблице users не будет часто обновляемых полец (last_visit), то эту таблицу можно перевести в MyISAM, а это несколько быстрее на селектах чем InnoDB.
Над более быстрое реализацией подсчета кол-ва пользователей онлайн подумаю.
Николай - сентября 20, 2007 18:57
Есть у меня похожий скрипт, лежит в каталоге «на доработку».
На серверной стороне (ASP.NET, IIS) крутится вечный инстанс веб-приложения (где-то у себя в блоге писал про это). Данные пользователя кешируются в памяти сервера и сбрасываются в базу с определенной периодичностью, либо по достижении порога объема кешированных данных.
Anton - октября 3, 2007 04:54
Если я правильно понял, весь пост можно вместить в одно предложение: «используйте memcached вместо СУБД»?! В чем «идея»?!
Денис Болтиков - октября 3, 2007 09:24
Идея в том как именно использовать.
Ты никогда не замечал, что все хорошие идеи простые?
Использование memcached для ускорение работы высоконагруженных проектов : Денис Болтиков - октября 10, 2007 13:46
[...] Пример использования мемкеша есть в одной из моих предыдущих заметок. [...]
Андрей Пивоваров - октября 13, 2007 00:29
Как я понял, для таких операций нужен отдельный сервер. Я с memcached не работал, если что — сорри за глупый вопрос: не каждый стартап может позволить себе второй сервер. А есть ли в природе сервис именно для виртуального хостинга memcached-серверов?
Денис Болтиков - октября 13, 2007 00:41
Физически это может быть один сервер, только памяти желательно побольше.
Андрей Пивоваров - октября 13, 2007 02:32
ну, в идеале, это должно быть ОЧЕНЬ много памяти. на стандартных хостингах столько не бывает:)
я как раз говорю о специализированном сервисе — за умеренную денежку отдельный аккаунт с минимально необходимыми опциями и максимумом памяти для memcached. ну и естественно, в железе ничего лишнего — только то. что нужно для этих целей...
Денис Болтиков - октября 13, 2007 09:49
Обычно гигабайты. На shared или VPS это конечно не сделаешь. А вот на collocation уже возможно поставить memcached на тот же сервер.
Про отдельные специальные сервисы не слышал и скорее всего таких нет.
Кстати разрабатывать сайт можно и на shared или VPS, только использовать не memcached, а эмулировать его через базу данных. Скорости не те, но механизм будет такой же. А на боевом сервере потом просто поменять библиотеку.е
alfa - октября 27, 2007 22:46
А что мешает использовать тип HEAP в mysql для таблицы who_online ?
Денис Болтиков - октября 27, 2007 22:57
Конечно это самые быстрые таблицы в mysql, но все равно это куча запросов к базе, особенно если на странице находится штук 40 ников (на каждый ник свой запрос) и так при каждом просмотре страницы.
Можно конечно делать один общий селект, пихать всех онлайн пользователей в массив, а потмо уже из него брать. Но все равно не то.
Мемкеш будет по любому быстрее.
alfa - октября 28, 2007 01:31
2Денис Болтиков
думаю не правы, по крайней мере когда я тестировал для нашего сервиса и новой системы авторизации варианты хранения текущих сессий в memcached или mysql то INSERT INTO ON DUPLICATE KEY UPDATE для отслеживания путей и сессий в HEAP спокойно пережевывало работу пять тысяч псевдо-пользователей. Выигрышь с мемкешем в данном случае был совсем небольшой, а удобство работы с мускулом переломило небольшую (совсем небольшую) латентность при запросе.
Хотя во всех остальных случаях мемкеш рулит.
Все же не нужно забывать что HEAP эта та-же оперативка что и в случае с мемкешем :)
zz - января 23, 2008 14:25
При больших объемах данных (eg селект из Таблицы с файловой системы порядка 6−7 секунД) MEMORY tables рулят :)
|
