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

Вот пока писал пост пришла в голову идея записывать информацию о последних N-постах в какой-то массив, его сериализировать и ложить в memcache. Наверное ложить в память стоит лишь ИД-юзеров, которые за последний час получили новые сообщения. При обращении доставать из памяти, производить десериализацию и проверять через isset($myarray[$user_id]) наличие нового сообщения для этого юзера в массиве. 

Критика? Предложения?

Т.е. правильно ли я понял, что ты хочешь навесить таймаут на функцию, которая будет опрашивать базу на наличие новых писем?
И как ты собираешься сделать это через аякс, разбить на фреймы, положив в 1 из них нужную функцию, или же запускать ее при загрузке контента?

да

А тогда вопрос, зачем так делать? Мне кажется, разумнее будет делать запрос при определенном событии, скажем, переходе на страницу. Ведь в большинстве случаев у тебя результатом будет 0.

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

Нагрузки никакой этот запрос не должен создавать, так как выбираешь только число, потом при переходе по ссылке юзером, вытаскиваешь необходимую инфу и показываешь, + кэш на уровне субд, если идет частое обращение к базе. Этот запрос у тебя в slow_queries попадает?
зы. какой серв и какая планируемая нагрузка?

Это пока лишь в теории.



ну, например, на сайте одновременно 10 000 людей сидеть будет. В среднем каждый юзер если будет страницу новую раз в минуту грузить, то это 10 000/60 секунд=166 запросов в секунду. В принципе это не так уж мало. А если проверять поступление новой почты через аякс, как задумано, например, каждые 10 сек, то это уже 10 000/6=1666 запросов в секунду. Т.е. дофига.

Memcache - это хорошая мысль. Только зачем массив? Для каждого пользователя отдельно хранить количество непрочитанных сообщений. При поступлении нового сообщения memcache_increment($prefix.$uid), при проверке memcache_get($prefix.$uid) и отдаем пользователю, если вернула false, то читаем из базы и пишем в memcache. При прочтении, соответственно, memcache_decrement($prefix.$uid) или memcache_delete($prefix.$uid).

Если нужна еще большая производительность, то можно написать демона, которым будет раздавать информацию о новых письмах.

ИМХо: лучший вариант. у Пети может за весь день письма не будет, а запросы идут, а так без них можно будет обойтись.

каким образом? ведь должен сначала запрос от клиента прийти.

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

Что жрет львиную долю ресурсов? В первую очередь любые механические действия (чтение/запись с жесткого диска). Удаленные запросы (loopback не в счет, но я сомневаюсь, что у вас и веб сервер, и БД, и memcache на одном сервере )

Т.к. демон будет висеть в памяти, а запросы будут идти напрямую(или, к примеру, через nginx), то для обработки запроса затраты ресурсов будут минимальны.

Добавлено через 3 минуты и 13 секунд
В упрощенном варианте примерно так  Далее уже детали реализации. Хотя для винграда, я думаю, более чем достаточно будет memcach-а

Это не только для Винграде. Я делаю расчет, что на другом портале одновременно будут по 20 000 юзеров на сайте. Не уверен, что хорошо будет если 20 000 переменных создать в мемкеше:

Тогда действительно стоит подумать о написании специального демона для этого.


Согласен. Из этих 20000 большинство несут бесполезную информацию, по этому нет смысла хранить их там все. Как альтернатива, помещать в мемкеш количество новых сообщений только для тех пользователей у которых они есть (тогда количество объектов будет на пару порядков меньше). Актуализировать информацию можно отдельным скриптом работающим через крон, к примеру, каждые 15 минут.

Не имеет смысла затрачивать процессорное время на сериализацию, когда данные в Memcache попадают уже сериализованными.
Тебе подойдет решение от Сталкера с Memcache и increment'ом по "unread-messages-userid".


Мелочь какая, 20к переменных. Для примера, у нас на одном Memcache сервере (на текущий промежуток времени) хранится 1270459 записей.