Комментарии 12
полезная статья.
Есть вот такое решение для счетчиков: saterenko.ru/2008/05/10/memcounter/
Насколько я понимаю, оно уже используется автором в одном из проектов, по описанию мне очень понравилось.
Насколько я понимаю, оно уже используется автором в одном из проектов, по описанию мне очень понравилось.
Собственно атомарных инкремента и декремента достаточно для реализации стандартных методов синхронизации.
Проверяем флаговую переменную. Если нет её в кеше — ставим равной единице, если есть и не ноль — цикл ожидания «освобождения» переменной. Если есть и ноль, тогда инкремент флаговой переменной. Читаем значение, если получаем — декремент. Если не получаем — лезем в базу, сет, декремент.
Если ждем долго — генерим эксепшн по факту блокировки.
Если ждем долго — генерим эксепшн по факту блокировки.
Существует еще один вид счетчиков, который без memcached или подобного ему решения вряд ли может быть реализован
MySQL heap table + raplace. Выбор по неравенству с использованием ключа по времени. Очистка мусора, аналогичная той, которую php по-умолчанию использует для очистки старых сессий. Будет нормально работать при довольно существенной нагрузке. Счётчик числа посетителей «online» без списка самих посетителей редко когда нужен.
Мне кажется, лучше преподносить материал как один из возможных способов, а не как истину в последней инстанции.
Memcached работает гораздо быстрее. Это не истина в последней инстанции, но кол-во запросов в секунду, которые способен выполнить MySQL на порядки ниже аналогичной цифры в memcached.
С технологической точки зрения — да. Но, мне кажется, что кроме оптимизации ради оптимизации есть ещё много интересных занятий.
А с точки зрения проекта видеть список присутствующих людей, а не только их количество скорее приятно, чем нет.
А с точки зрения проекта видеть список присутствующих людей, а не только их количество скорее приятно, чем нет.
Я не понял последний абзац про людей.
Эти посты — о memcached, и действительно без него или подобного ему сделать описанный счетчик вряд ли удастся на нагруженном сайте. Когда цифры будут добираться, например, до 30000 человек поситетелей, нам нужно будет инкрементировать счетчик 100 раз в секунду (если считаем онлайнеров за 5 минут = 300 секунд). 100 запросов в секунду для БД является паразитной нагрузкой, т. к. она умеет многое, но ради фактически увеличение значения ключа выполняет очень много посторонней работы, лучше те же 100 запросов в секунду отдать под полезную для БД функциональность.
Эти посты — о memcached, и действительно без него или подобного ему сделать описанный счетчик вряд ли удастся на нагруженном сайте. Когда цифры будут добираться, например, до 30000 человек поситетелей, нам нужно будет инкрементировать счетчик 100 раз в секунду (если считаем онлайнеров за 5 минут = 300 секунд). 100 запросов в секунду для БД является паразитной нагрузкой, т. к. она умеет многое, но ради фактически увеличение значения ключа выполняет очень много посторонней работы, лучше те же 100 запросов в секунду отдать под полезную для БД функциональность.
100 раз в секунду — как раз плюнуть.
Я понимаю, что статья про memcached. Я, конечно, извиняюсь, что сбиваю тему, но я просто не удержался и прокомментировал цитату про вероятную невозможность иных решений.
Мне бы не понравилось если бы задача по выводу списка людей «онлайн», решалась так: «Аналитическое исследование показало, что реализация данной задачи приведёт к „паразитной“ нагрузке, исчисляемой 100 запросами каждую секунду, поэтому было принято решение отказаться от вывода списка, а выводить и вычислять только количество». Другое дело, если бы ответ был бы таким: «Вывод списка посетителей „онлайн“ потребует дополнительных вычислительных мощностей». Я могу представить, что такое может случиться, может быть, в случае проекта на 1 000 000 пользователей и 10 000 000 обращений в сутки, 5000 в пике (ткнул пальцем в небо).
На моей практике такого не было, скажем, даже при общей нагрузке в ~500 запросов в секунду к базе (пиковое значение) если говорить конкретно про этот способ. MySQL в умелых руках, всё же, не так плох, как его представляют.
Я понимаю, что статья про memcached. Я, конечно, извиняюсь, что сбиваю тему, но я просто не удержался и прокомментировал цитату про вероятную невозможность иных решений.
Мне бы не понравилось если бы задача по выводу списка людей «онлайн», решалась так: «Аналитическое исследование показало, что реализация данной задачи приведёт к „паразитной“ нагрузке, исчисляемой 100 запросами каждую секунду, поэтому было принято решение отказаться от вывода списка, а выводить и вычислять только количество». Другое дело, если бы ответ был бы таким: «Вывод списка посетителей „онлайн“ потребует дополнительных вычислительных мощностей». Я могу представить, что такое может случиться, может быть, в случае проекта на 1 000 000 пользователей и 10 000 000 обращений в сутки, 5000 в пике (ткнул пальцем в небо).
На моей практике такого не было, скажем, даже при общей нагрузке в ~500 запросов в секунду к базе (пиковое значение) если говорить конкретно про этот способ. MySQL в умелых руках, всё же, не так плох, как его представляют.
juks, я не спорю, что это можно сделать с помощью MySQL. Можно с помощью локальных файлов, можно с помощью еще чего-то. Например, если у меня одна морда, можно в shared memory хранить — будет куда проще и быстрее.
Но memcached выдержит гораздо большую нагрузку (чем MySQL), его API в данной ситуации даже проще, чем у БД. Memcached может быть полезен для проекта не только для счетчика онлайнеров, и здесь тоже его можно применить.
Согласен, что фраза «только на memcached» некорректна, будет правильнее написать «что достаточно эффективно» или «гораздо лучше, чем на MySQL».
Но memcached выдержит гораздо большую нагрузку (чем MySQL), его API в данной ситуации даже проще, чем у БД. Memcached может быть полезен для проекта не только для счетчика онлайнеров, и здесь тоже его можно применить.
Согласен, что фраза «только на memcached» некорректна, будет правильнее написать «что достаточно эффективно» или «гораздо лучше, чем на MySQL».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атомарность операций и счетчики в memcached