Вы ведь наверняка выделили под memcached отдельный сервер? Вообще, в нём же можно хранить данные сессий (а ещё, например, готовые html – уже сгенерированные по типу ob_start/end)… У меня где-то даже класс завалялся, для работы с сессиями в memcached. Однако – тут встаёт более хитрая проблема. Данные в memcached имеют свойство пропадать (например при потоке 100 новых сессий в секунду + кэш запросов + ещё что-то) старые данные у вас просто вытеснятся, и юзера выкинет. В общем, всё не так то наглядно. Как вариант можно хранить данные с избыточностью, например.

memcache… бррр что-то лично мне он не нравится.. для кеширования я использую след. схему:

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

идея сама в использовании tmpfs (типа RAM-DISK. не знаю я как в винде это правильно называется). TMPFS – это файловая система, которая представляет собой часть ОЗУ, примонтированной в определенную точку.. так вот по поводу папки cache, примонтировать в нее tmpfs, и туда уже сохранять в кеш. соответственно эти кешированные данные лежат не на диске, а в ОЗУ.

так же поступить и с сессиями. надеюсь, не нужно разжевывать.

—

по поводу ведения статистики – если не критично, то можно инфу просто сохранять в конец файла. т.е. к примеру одно обращение к серверу – 1 строка в файле. и так заполнять. а в более разгруженное время суток, когда сервер “расслабляется”, уже парсить файл и сохранять в базе инфу.

Для начинающего (растущего) программиста, менеджера проектов подобную информацию не найти. Она очень ценная. Спасибо.

>> Во всех системах статистики производится частые вставки (INSERT) в одну таблицу или группу таблиц…
Во всех системах статистики ведется т.н. промежуточное кеширование информации. Т.е. висит себе демон в памяти и сбрасывает все в файлик с критической частотой. А по расписанию кидает все в базу (вспоминаем пересчеты статистики li.ru и иже с ними)

>> Другой случай может оказаться сложнее, и в другую БД будет писаться информация, которая потом будет использоваться на проекте (на основном сервере). Поэтому данные двух баз данных нужно как-то синхронизировать.
Схему репликации Master-Master крайне не советую использовать.

По поводу базы. Некритичные данные можно инсертить на мастер-сервер, а забирать из слейв-сервера. Но такая схема работы подразумевает жесткое условие: Идет обновление данных – работаем с мастером. Идет чтение – работаем со слейвом. На проектах, с 1к запросами в секунду (биллинг) только так и получается балансировать на грани сохранения резерва вычислительной мощности двух серверов.

>> Сессии, как и база данных, по сути, является файловым хранилищем (файлы сессий хранятся на жестком диске сервера), поэтому обращение к ним следует минимизировать.
Даже если вы уберете данные из сессии, то идентификатор-то все-равно лежит на ФС. А скорость доступа к файлу, в основном, зависит от скорости поиска. Т.е. изменение размера файла сессии с 5кб на 1кб вы ничего не получите. Только геморрой и будете тратить лишнее процессорное время на операции анализа куков (или, неявно, воспользуетесь стандартным разборщиком). Обратите внимание, что от хранения файлов сессий на ФС вы так и не отказались

>> Скрипты, как их не оптимизируй создают большую нагрузку на процессор.
Число пи высчитываете? При загрузке процессора 0.75 php-cgi (спаунинг) ест не более 0.01. Остальное – СУБД.