Собственно проблема: пишу чат, существует скрипт, к которому каждые несколько секунд, через Ajax, обращается страница. В нем есть сессия(если еще нету, то создается), в которой метка time() предыдущего вызова этим пользователем. Дальше из БД берутся все сообщения с этой метки до момента сейчас, и этот момент сейчас, в свою очередь, записывается в сессию для следующего вызова.
Это была версия №1. Ее недостаток - если файл вызывался в начале секунды, то сообщения, добавленные в конце той же секунды не доходили до пользователя.
В следующий раз попробовал делать выборку до момента сейчас, НЕ включительно(то есть не " AND timestamp <='.$stime", а " AND timestamp <'.$stime").
Недостаток - зачастую приходиться очень долго ждать прихода сообщений. Сообщение уже пришло, но из за вышеописанной особенности не возвратилось вовремя и придется снова ждать таймера JS, вызывающего Ajax, снова ждать посылки запроса, ответа сервера....
Потом пришла в голову идея дождаться в PHP окончания текущей секунды, а потом сделать все тоже самое, как и в варианте №1. Но тут есть две проблемы: долго ждать ответа сервера, и я не знал загружает ли мой код ожидания сервер(если каждый вызов будет держать процессор загруженным по пол секунды никаких мощностей не хватит)
Поэтому решил попробовать с функцией microtime, как в варианте №3, дожидаться окончание текущий миллисекунды(этот способ лишен вышеописанных недостатков). Но это, разумеется, не сработает, если функция недостаточно точна(данная идея пришла в голову от того, что все говорят что профилер на ней точный невозможно построить)
Заранее спасибо за ответы, с уважением, Александр

Код, вариант №3, для наглядности:


Это сообщение отредактировал(а) theworldcreator - 12.7.2008, 21:09

Гениально. Вы случайно родом не из Индии?

Проблема, судя по всему, в кривизне структуры БД. Предлагаю выложить в этом топике полную ее схему.

Это промежуточный вариант,  все равно менять, и мысль двигалась в следующем направление: если пустые итерации цикла 100% займут процессор, то, скорей всего, встроенная функция откладывает продолжение выполнения скрипта, а не работает впустую. А поскольку этот вариант все равно промежуточный, реальное тестирование производительности было отложено до лучших времен.



Изначально задача была такая: отдавать еще не прочитанные сообщения. Сразу пришли в голову две мысли: хранить где то список ID уже прочитанных(мне этот вариант показался очень ресурсоемким) или хранить где то время, по которое пользователь уже получил сообщения. Собственно здесь реализован второй вариант. Структура:
message    text
mdate    int(11)

Помимо этого есть еще несколько полей, но они сейчас никак не влияют.

а мне вообще кажется что микротайм это весьма относительно ведь ещё скорость выполнения скрипта до микротайма какая ? тоже же миллисикунды.

theworldcreator, 

Используй не метку времени, а ID последнего полученного сообщения.

Т.е. на текущий момет ты получил сообщения по ID = 100 включительно.
Значит в следующий раз ты должен получить все сообщения которые имеют ID > 100

Так будет гораздо устойчивее.

Хм, а об этом я не подумал. Спасибо большое!
Но таким образом решается лишь эта конкретная задача. Все равно очень интересно, насколько точно она работает, и если достаточно, то почему все ругаются на нее, как на основу профилера?

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

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