AJAX и время запросов

[lliberty]

Небольшое описание системы:
1. Имеется сервер и клиент. Взаимодействие через AJAX
2. Пинг до сервера пусть будет 70мс
3. Время выполнения скрипта 5мс

Если запрос происходит через GET, то данные с сервера приходят через 75-80мс. Проблема в том, что используются запросы POST (т.к. серверу для работы необходимо отправить 1-2кб данных, которые сейчас хранятся у клиента), и тогда данные с сервера приходят уже через 150-160мс (из-за отправки двух пакетов при POST (заголовок и сами данные) вместо одного).

Заказчик проекта считает что раз пинг до клиента 70 мс, то и данные он должен получать за примерно такое же время, но никак не в 2-2,5 раза дольше. В чем-то он прав, т.к. проект связан с веб-доступом к удаленной СУБД и время тут критично.

Я сейчас прикинул 2 варианта:
1) Берем данные клиента (в JSON), сжимаем их LWZ, затем переводим в Base64. Подставляем в адресную строку и отправляем как GET запрос. Минимум изменения кода как на стороне клиента так и на сервере. Опасность, влезет ли даже такой сжатый запрос в GET...
2) Хранить сами данные клиента на сервере (Memcached). На действия клиента формировать небольшие GET запросы (добавил/изменил/удалил часть запроса). Но, тут необходимы серьезные изменения в логике работы как серверной, так и клиентской частей.

Собственно вопрос к опытным программерам, может можно еще как-то загнать "большой" запрос в GET (сессии? Coockies? ???) ? Я согласен что вариант (2) более оптимален, но хотелось обойтись "малой кровью", а не переписывать пару мегабайт PHP и JS текстов...

[Gvozd]

3. Время выполнения скрипта 5мс

фантастика!

из-за отправки двух пакетов при POST (заголовок и сами данные) вместо одного

чего?
что за бред?

я бы на вашем месте:
1) замерил бы скорость выполнения самого скрипта при разных случаях.
практически уверен, что при POST-запросе тормозит именно скрипт, либо выполняемые им запросы к СУБД
2)воспользовался бы фаербагом.
он прекрасно показывает на какие действия было потрачено время при каждом запросе.
вполне возможно, что тормозит какой-то из сетевых этапов.
я например однажды видел, как на локалхосте страница грузилась несколько секунд.
из них практически все время занимал DNS_запрос

[lliberty]

Тестил вчера, долго и упорно.
1. Время выполнения я замерял в PHP через microtime(), схематично так:

<?php
$tstart = microtime(1);

//<---
Коннект к базе, memcahced
Сам скрипт
//--->

$tend = microtime(1);
echo round(1000000*(tend-tstart));
?>

Полноценные запросы 7-10 мс (разумеется при условии что нет сложных выборок из базы, либо выборки закешированы).


А вот с POST не бред.
Сделал такой маленький тест, вместо полноценного скрипта, php-заглушка.

<?php
 echo 'test';
?>

Делаем к этому скрипту Ajax-запрос методом GET. Время отклика (firebug) 60-80мс.
Изменяем скрипт и делаем запрос методом POST. И, фантастика, время загрузки резко увеличивается до 140-180мс. нет никаких запросов к базе, скрипт не меняли (firebug показывает, что основное време тратится на "Ожидание", в то время как "DNS", "Подключение" и "Отправка" по нулям, "Загрузка" 3-5мс).

Далее, переделал 1 простой запрос (выборка 1 значения: обращение к memcached и к базе если нет в кеше) от клиента к серверу из POST в GET. Обработка данных такая же, а время загрузки ответа от сервера упало с 170мс до 70-90мс.

Далее, отказался от PHP. Написал небольшую fcgi-c++ программку (выборка 1 значения из таблицы). Запустил на сервере. Запросы POST к ней идут 150-300мс. GET запросы 65-100мс.


Цитата перевода статьи с developer.yahoo.com

Команда Yahoo! Mail обнаружила, что при использовании XMLHttpRequest, POST выполняется в браузерах как двухэтапный процесс: сначала отправляются заголовки, затем данные. Поэтому лучше использовать GET, который отправляет только один TCP-пакет (если только у Вас небольшое количество cookies). Максимальная длина URL в IE - 2K, так что, если Вы посылаете больше, чем 2 К данных, то Вы не сможете использовать GET.

Был обнаружен интересный побочный эффект: POST без отправки каких-либо данных, ведёт себя как GET. Согласно HTTP-спецификации, GET предназначен для получения информации, поэтому имеет смысл (семантически) использовать GET только тогда, когда Вы просто запрашиваете данные, а не передаёте их для хранения на стороне сервера.

[Gozar]

удалено.

[Gvozd]

чтож.
не знал о такой нерациональности в XMLHttpRequest

Собственно вопрос к опытным программерам, может можно еще как-то загнать "большой" запрос в GET (сессии? Coockies? ???) ? Я согласен что вариант (2) более оптимален, но хотелось обойтись "малой кровью", а не переписывать пару мегабайт PHP и JS текстов...

сессии они исключительно на сервере, через них информацию с клиента не передашь.
попробуйте с куками поэксперементировать.
Задача весьма нетривиальная.

[Gozar]

удалено.

[Gozar]

удалено.

[lliberty]

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

Абсолютно согласен. Но тесты по 100-200 запросов подряд, примерно в одно и то же время суток, и на одном и том же (абсолютно не нагруженном в данный момент VDS) я думаю более-менее объективны ))
Про лоадер согласен, но при частоте подгрузки 5-6 раз в минуту, мелькание лоадера (пусть даже на секунду), мне кажется наоборот, еще сильнее будет раздражать посетителя))

Скорее всего вы придете к тому что ваше время задержки будет съедаться в другом месте и оно будет больше чем изначальное без извратов.

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

ps: а вообще похоже на, я написал кривое приложение или наобещал невозможного, а теперь меня не устраивает как работает протокол, технология, сервер и т.д. Кто-то здесь точно не прав и это не POST.

Похоже)) Но идея немного другая: "если физически (используя другой протокол) можно увеличить скорость отклика сервера в 1,5-2 раза, то почему бы это не сделать?"

Если размер данных одинаков и заранее известен...

Хех, в этом то и облом что неизвестен...

[Gozar]

удалено.

[Gozar]

удалено.