rPman

1. необходимо любым доступным способом отлавливать появление новых записей в базе (так или иначе это можно сделать либо в приложении, которое пополняет базу, либо тригером, совершающим действие 'снаружи', если ничего удачного БД не позволяет… периодически (в 2 раза чаще чем самый короткий интервал) делать максимально простой запрос — например текущее значение сиквенса в табличке
1. пишется демон (1 процесс), который должен ловить событие от появления записи в БД и вычислять время срабатывания ближайшего таймера (простейший запрос к табличке, сортировка по времени срабатывания таймера — лимит 1) и ждать либо срабатывания таймера либо следующего события добавления записи

Почти наверняка проблемы с вебсервером или может быть DNS?

gentoo, apache, тормозной старенький AMD Sempron(tm) Processor 3400+

a.php: <?php echo str_repeat('0123456789012345',8192); ?>

# date; curl http://localhost/a.php >/dev/null;date
Втр Авг 9 20:15:03 NOVST 2011
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 128k 0 128k 0 0 31.4M 0 --:--:-- --:--:-- --:--:-- 41.6M
Втр Авг 9 20:15:03 NOVST 2011


p.s. но если у вас тоже самое с cli php то нужно бить тревогу!!!

p.p.s. у меня на first vds был момент, когда простейший lib_curl (точнее вызовы curl_… из php) нещадно подвешивали виртуалку под 100% на секунды, но в то же время консольная утилита curl/wget — работали без проблем… пока вообще выяснял, откуда тормоза, проблема самоустранилась (длилась часами), поэтому записал на счет потенциальных глюков openvz (точнее virtuozzo) и сделал зарубку в памяти, что и такое возможно.

PHP не очень пригоден (точнее не предполагает подобного использования, но формально ничто этому не мешает) для использования как постоянно запущенной службы, вместо режима частых и коротких запусков

Соответственно, можно использовать асинхронные сокеты (см. socket_set_nonblock и socket_set_option, первый же пример в гугле) в php и серверную часть запускать в виде одного процесса (со всеми вытекающими проблемами из-за потенциальных багов в коде, точнее прервутся все соединения, если упадет это приложение), либо на каждое соединение запускать по процессу, с обычными сокетами, но тогда добро пожаловать в мир semaphore и shared memory (конечно, можно и без них, используя типичный LAMP подход, когда за синхронизацию отвечает БД с транзакциями, но производительность будет ужасная и вас засмеют за говнокод).

p.s. Сильно не копал, возможно есть куча готовых фреймворков или даже расширений PHP, добавляющих событийный функционал.

в догонку к вышесказанному:
1. если СЕО позволяет, постарайтесь побольше делать на стороне клиента (javascript templates/ajax/..) и поменьше на сервере

2. не экономьте на разработке кода-управления кластером (а для высконагруженных проектов кластер нужен хотя бы для надежности): скрипты обновления (а и в проекте необходимо учесть что его код и данные могут обновляться), резервирование и восстановление из резервной копии, управление кластером — добавление/удаление/настройка узлов, и т.п.
Просто при плохой организации высоконагруженные проекты глючат чаще :) потому что банально 'тестеров' больше.

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

4. оптимизация sql это круто, но очень часто nosql решения (+что то по сериализации) вполне себе заменяют sql (а уж по скорости безусловно побеждают), как вариант — комбинированные решения (но последнее порождает чуть больше проблем при обновлениях структуры и кода)
* memcached — это кстати тоже nosql, только не является хранилищем (не гарантирует что если данные сохранил, то их можно будет извлечь)
* вот в решениях хранения не стоит городить собственных велосипедов и не стоит изобретать кошмар на файлах. НО, например небольшие статичные (редкоизменяемые) куски БД гораздо эффективнее подгружать прямо в виде PHP массива (до размера сотен кб php код иннициализации переменных работает значительно быстрее любого БД-фреймворка, не говоря уж про накладные расходы на соединения с БД и т.п.)

P.S. будьте готовы все переписать, это актуально для развивающихся проектов, т.е. сначала используя сложные но готовые средства реализуется что то работающее, на чем обкатывается бизнеслогика, затем, когда этот монстр становится просто неповоротливым, на основе готового, с нуля, реализуется новый проект, без болячек роста, быстрый и простой.