Однажды я столкнулся с такой проблемой: на странице сайта с помощью PHP-скрипта выдавался пользователю видео-контент (подробнее в моей статье «flash-видео на веб-страницах и PHP»).

Скрипт, «отдающий» видео, работал долго (примерно столько же, сколько длился видео-ролик: мы установили контроль скорости скачивания согласно битрейту). Так вот, если в период просмотра видео вы открывали новый таб в браузере с другой страницей этого же сайта, возникала ошибка.

Ларчик открывался довольно просто. На сайте использовалась авторизация, основанная на стандартных PHP-сессиях. Так вот, когда сессия стартуется, сессионный файл блокируется, и до тех пока сессия не закроется и файл не разблокируется, никто не может открыть файл сессии. По умолчанию сессия закрывается при окончании работы скрипта. Мы добавили непосредственно перед выдачей видео-контента строку session_write_close() — вуаля, все заработало.

Поскольку совсем недавно товарищ пожаловался на точно такую же проблему и был рад полученной подсказке — я решил поделиться этим «хинтом» с хабралюдьми.

Небольшая предыстория.

У меня есть хобби-проект трекер.ру
Алгоритм такой: пользователь вводит поисковый запрос, этот запрос «на лету» ищет торренты на сторонних трекерах (рутор, рутрекер, tfile и тд).
Для параллельного поиска идет одновременно несколько аякс запросов, которые должны обработаться асинхронно.
Однако, запросы выполнялись синхронно. Если какой-то трекер долго не отдавал ответ, то остальные запросы подвисали и ждали ответа от подвисшего трекера. Общее время выполнение запросов равнялось сумме всех запросов. Хотя, по моим планам общее время должно было равняться самому долгому запросу.
Долго ломал голову, почему так. Грешил на HTTP pipelining. Но, причина оказалась намного банальней. Все дело в сессиях. Дело в том, что сессии в php консистентны и php не даст обратиться другому процессу к уже занятой сессии.