Здравствуйте.
Реализовал ajax следующим образом:
После нажатия на кнопку "отправить", форма отправляется в скрипт, с выводом во фрейм.
Во фрейме происходит запуск JS функции с параметрами.
Данная функция в цикле создает ajax запросы (очередью по 5 штук). Цикл может состоять из 30 итераций. каждый ajax запрос посылается в один и тот же php скрипт, назовем его receiver.php, запросы отличаются лишь параметрами.
receiver.php используя curl обращается к внешнему сервису, передает ему параметры, получает значения и отвечает обратно, так что бы ajax принял ответ и отобразил на странице.

Так вот, верно ли я понимаю, что receiver.php в данном случае не может обработать следующий запрос до тех пор, пока не обработан предыдущий?

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

Ага, причем нельзя быть уверенным какой из ответов в очереди ты получишь на последний свой запрос.
Предположим скрипт отрабатывает 2 секунды.
Отправив 20 запросов в течении 7 сек - получишь в браузер неизвестно какой из трех ответов.
Никакой синхронизации. Велком ту веб.
Сенкс фор браузерс спид оптимизейшн.

Может, если:
0) браузер не будет своевольничать, стоит к урлу скрипта добавить какое-нибудь случайное значение, чтобы запросы шли на один скрипт, но по разным урлам.
1) сам сервер не будет мешать. В частности, скрипт не использует сессии (или быстро отпускает - см. функцию session_write_close)

Ну тут я проблему решил, скрипт возвращает ответ с параметром, например id, а JS в свою очередь обновляет на странице элемент c этим ID.


Если речь идет о различии в параметрах, то да, это уже реализованно.


1. session_write_close, как я понял, должен стоять после обработки скриптом? В этом случае опять же, пока скрипт не обрабоатет предыдущий запрос, session_write_close не будет. Т.е. по сути, в данном случае session_write_close ничего существенно не сделает, или я не так понял сути session_write_close ?
2. К тому же, у меня авторизация, в том числе, завязана на сессиях. Неизвестно как поведет себя механизм авторизации в этом случае и какие новые баги всплывут.

Верно ли я понял, что ситуация с отсутствием параллельности связана с тем, что все запросы выполняются в рамках одной сессии? И различия в параметрах не имеют значения.

Речь о том, как параметры передаются. GET - будут разными урлами, POST-нет.


Нет, тогда, когда сессия больше не нужна в этом скрипте и её можно отпустить.
Сессии - механизм блокирующий, session_start будет ждать write_close, если эта сессия была уже открыта в другом запросе.
session_write_close вызывается автоматически при завершении скрипта, поэтому что будет со всякими авторизациями как раз заведомо известно - ничего не изменится.


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

Шикарно. session_write_close() действительно помог, спасибо Вам.

Но в этом случае receiver.php выполняется так же, в одном потоке. По сути, все скрипты в apache выполняются в одном потоке, Если не используется pcntl и немного бубна , верно?

Т.е. в случае использования session_write_close() , выполнение receiver.php может быть потенциально "опасно", так как нет синхронизации.. верно я понимаю этот момент?

Вообще, на сколько правильно использование session_write_close() в моем случае, когда есть много клиентов и каждый часто шлет по ~30 запросов в скрипт?

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

А вы сессии использовать не боитесь? Это ведь их штатный механизм и есть.
Хоть я некоторое время назад и разбирал исходник сессий, как реализован механизм блокировок - не знаю. Могу только предположить, что о конкурентном доступе позаботились.
Под никсами скорей всего используют flock, т.е. безопасно.