как лучше реализовать количество просмотров страницы?

Я бы базу дергал - все равно это быстрее чистого файлового IO, да и посещалка вряд ли поднимется высоко

Прикрутить готовый счётчик?

memcached, redis

Раз в час/день/месяц (нужное подчеркнуть) сбрасывать в persistent storage.

Что мешает использовать сторонний счётчик?

Для бложика на php в один файл «делать запись в базу +1» самое оно)

Ну во-первых, сессия сэкономит тебе обращения, а во-вторых, с твоим бложиком тебе вообще не нужно об этом думать.

А держишь сайтец где?
Вообще, присоединяюсь к варианту - не стрёмно дёргать базу.

В смысле - на ноутбучном винте может... если он паркует головки через микросекунду после работы - не вариант тогда.

Нагрузка какая? Десяток просмотров в секунду если, то не заморачивайся, пиши в базу просто.

знач сделал так... установил memcached, включил хранение php сессий в memcached:

session.save_handler = memcached
session.save_path = "127.0.0.1:11211"

теперь таким образом подсчитываю количество просмотров страниц и синкаю с БД:

    if ($_SESSION['blog']['post_id']["$post_id"]++ == 0 || ($_SESSION['blog']['post_id']["$post_id"] % 8) == 0) {
      $sq3->query('
        UPDATE blog_posts
        SET post_views = post_views + '.$_SESSION['blog']['post_id']["$post_id"].'
        WHERE post_id = '.$post_id.'
        ');
    }

$_SESSION -> Memcached -> SQLite3

синкаю с базой первый раз при первом же просмотре страницы и плюс еще идет подсчет в сессии, сколько раз страница была просмотрена. а затем уже синкается только при каждом 8м просмотре страницы. все правильно? :3

UPD: вейт. надо еще при каждом (посещении % 8) сбрасывать счетчик в сессии. и тогда ок.

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

а у тебя разве база не дёргается для того, что-бы проверить куку и т.д? Откуда ты знаешь, что это за юзер?

пользователь логинится на сайте один раз, проверяется по базе, да.

а далее его пользовательский ID запоминается в php-сессии и по базе чекать его более нужды нет.

сессия это одна единственная кука (PHPSESSID) с уникальным ID, и далее php берет данные сессии из файла который хранится локально.

получается схема, навроде: пользователь с кукой «PHPSESSID» -> берем данные из файла /tmp/PHPSESSID.txt -> тут записано что это за пользователь, проверять его по базе лишний раз нужды больше нет.

вы наверно первый раз об этом слышите? ну просто знайте, что так оно работает и это вполне себе секурно.

да, сессии можно подменить, установив в куку сессию админа сайта, и это плохо, но это уже другой разговор. :) для примерна, ВКонтакте, там сессия хранится в куке «remixsid». вы можете подменить это значение на куку какого-нибудь свеого друга, знакомого (тоже взять из его браузера), - и вуаля, вы ВКонтакте залогинены как этот ваш знакомый. но так это работает и это нормально.

так вот. по SQL-базе оно не чекается при каждом посещении страницы (а только один раз при логине), а пользователя всегда помнит его сессия.

надеюсь понятно. :)

UPD: в дополнение скажу, что да, php-сессии это тоже отдельная база, но хранится лично у меня она не в SQL базе, а в Memcached (которая хранится в ОЗУ и очень-очень быстрая). по-умолчанию же php хранит сессии в файлах.

и далее php берет данные сессии из файла который хранится локально.

почему не из базы?

вы наверно первый раз об этом слышите?

нет. Видел много раз.

да, сессии можно подменить, установив в куку сессию админа сайта, и это плохо, но это уже другой разговор.

ваши проблемы.

так вот. по SQL-базе оно не чекается при каждом посещении страницы (а только один раз при логине), а пользователя всегда помнит его сессия.

ну про безопасность не будем, ладно. Почему вы думаете, что это быстрее?

но хранится лично у меня она не в SQL базе, а в Memcached (которая хранится в ОЗУ и очень-очень быстрая).

СУБД тоже кешируется.

Почему вы думаете, что это быстрее?

предлагаешь при каждом запросе пользователя слать логин-пароль?

отвечу на все сразу: не знаю тонкостей, что, зачем и почему. но так делают все. и всем норм.

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

предлагаешь при каждом запросе пользователя слать логин-пароль?

нет, я предлагаю хранить сессию в БД, а не в локальном файле.

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

поставьте венду, сделайте страничку фконтакте, и не лезте в программирование. Даже на php. Так все делают.

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

смогут. Впрочем, вы сами сказале выше, что вас глюки и безопасность не волнует.

это уже мелочи, тем более он написал что хранит в memcached

это уже мелочи

не получилось мне ещё один свой бред приписать? Ну извини.

тем более он написал что хранит в memcached

результат memcached обычно чуть менее, чем никакой. Все файлы php кешируются, делать для них ещё одно кеширование имеет мало смысла. Разве что мы в какой-нить Windows95, которая кешировать не умеет(?).

проблема в том, что твой memcached не умеет многозадачности, потому два скрипта запущенные одновременно будут работать неправильно. Т.е. данный подход в чистом виде не пойдёт даже для задач с нагрузкой «я и моя кошка». Хотя ты конечно можешь кричать дальше, и рассказывать про разные костыли и подпорки.

результат memcached обычно чуть менее, чем никакой.

дальше не читал

дальше не читал

молодец. Ибо кеширование помогает обычно в случае кривого быдлокода.

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

Яндекс.Метрика.

Всё уже придумано и реализовано, не стОит строить велосипеды.

Каждый восьмой? То есть ты будешь подсчитывать с точностью не более, чем 8 посещений? Имхо очень грубо.

Лучше записывай время создания счетчика и после инкремента проверяй сколько он уже лежит. Если больше чем T, то сбрасывай в БД. Ну и вытащи наружу ручку, типа flush counters, которую дергай по крону.

И да, у тебя с конкурентым доступом сделано все фигово. Проставляй счетчик с помощью cas-а. Почитай что это. http://php.net/manual/en/memcached.cas.php

это будет причиной таймаутов в БД.

Если делать по-умному, то надо не апдейт делать, а инсерт новой строки. А регламентом по крону - сворачивать все это дело в одну строку.

Если движок innodb, то не должно лочить на апдейт всю таблицу, только строку.

да, но строка-то будет одна на одну веб-страницу! А если ее 100 пользователей открывать начнут?

А вдруг война? :) Тут вообще не озвучили требования по нагрузке. Но судя по уровню вопроса, не думаю что тут хайлоад на 100 рпс. А несколько апдейтов в секунду - это фигня.

Инсерт - норм решение, только потом нужно будет по крону статистику сворачивать, а это доп сложность. Но тс так и не пишет требований.