Распределение нагрузки для Ajax приложений
 

Сабж.
Есть страница которая одномоментно(почти) генерит от 4х и более ajax запросов к серверу.
Время работы одного скрипта - от 30мсек до 1сек ( в зависимости от кешируемости)
Так как запросы идут к одному серверу - колличесво одномоментых запросов лимитированно.
Статистика показывается что след запрос начинается при начале получения данных по предедушему.
(график)
http://esosedi.ru/img/bench.jpg
Вначале я решил схитрить и скриптом менять домен от dc1.myhost.ru до dc6.myhost.ru
все висят на 6ти разных IP на двух разных серверах..
Вот думаю круто будет работать..
Ан нет, запросы на "не мой домен" не шлются :(

Попробовал запрокрировать через Mod_proxy
теперя при обрашении myhost.ru/dc1/... просходило проксирование запроса на другой сервер...

Нагрузка и время работы скрипта уменьшились( но не много )
А вот время ожидания клиента - не именилось..
Браузер все также ждет окончания пред запроса.
Точнее как я понял это не браузер - это апача в один момент времени от одного клиента обрабатывает только один запрос( никто не знает как пофисить? )

В общем помогите люди добрые ускориться

memcached

Люблю людей пишущих глупые и короткие предложения.
Практически не кеширумые у меня запросы :(
Время работы скрипта - мизер.
Время ожидания - дохрена.
Склеивать запросы в один "огого" запрос.. мм не рентабельно однако.

Данные вычисляются где?
Да где бы они не вычислялись из памяти их достать быстрее чем вычислить, засунуть в память, прочитать из памяти, очистить память.

PS - Если просите о помощи, любому ответу должны быть рады. В следующий раз сразу на йух пошлю. Невежа.

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

К сожалению если изменить URL адрессацию то упадет вся система кеширования, в частности клиентского.
Так как урл есть ммм.. адресс ноды квадродереве.
Тут или длиинные предлинные урлы писать, либо както еще.
Но одно из ограничений времени рекции - это время скачивания файла.
В приципе распределись нагрузку можно очень просто отказавшить от "браузерного" ajax и вернувшись на старые добрые ифреймы( им обрашение на домен третьего левела не страшно).. но не красиво это както. Чисто програмерски.

2Jooz
Простите конечно, но ответ из одного слова( и не по теме) это не ответ. Или Вы имели в виду что-то более полное и интересное?

Именно, кэшируйте данные на ajax в memcached и дальше уже дергайте сформированное из памяти не напрягая БД да и в целом файловую систему. Получите значительное повышение производительности.
Отклик моментальный.
Какую библиотеку ajax используете? Или что-то самописанное?
Я раньше сам не пользовался, но с недавнего времени (по совету одного хорошего человека) все свои проекты перевожу именно на memcached результат нагрузка на cpu упала в 70! раз, нагрузка на диски в 190! раз, нагрузка на память в 30 раз. Суммарная генерация страничек упала с 0.5 - 0.03 до 0.003 т.е. в 10 раз минимум.
Попробуйте, можно поставить на freebsd из портов + для php нужно будет скачать библиотеку.
PS - такие проекты как лайфджорнал и одноклассники юзают именно эту фитчу, судите сами. Да и вообще мемкеш был заказан и разработан именно по инициативе лайфджорнала.
Особенно он выручает именно в уменьшении запросов к базе (читать + к диску). Например, у меня один не большой сайт 5-6К человек в сутки и порядка 10-15К просмотров, генирит в час не более 200 запрос select хотя база очень наворочена и построена на много под уровневой реляции. В том числе и с использованием ajax (JsHttpRequest)

PS - для общего представления
http://ru.wikipedia.org/wiki/Memcached
Для perl можно почитать тут
http://www.opennet.ru/base/dev/perl_memcached.txt.html
Для php читаем ман или гуглим

Можно не менять URL. Если у Вас запросы одномоментные, то можно их собрать в массив и передать в качестве параметра этот массив. А потом уже в пхп-скрипте разложить массив и сделать нужные запросы.
Если вызов запросов осуществляется параллельно, но из разных мест, то можно их кэшировать на стороне клиента, а потом через определенные интервалы собирать в массив и отправлять на сервер.

JsHttpRequest использует ифреймы, если отключены активх. Так что нет в этом ни чего зазорного. Другое дело, что настройки многих клиентов будут убивать ифреймы.

Так проблема на сколько я понял не в скорости выполнения скриптов на стороне сервера, а в последовательном характере выполнения нескольких одновременных запросов. memcached не даст здесь ощутимого прироста скорости.