Вывод сообщений в реальном времени (JS + PHP)?

Question

[Кирилл Сидоров]

Как организовать вывод сообщений в браузер в реальном времени? Объясню по-подробнее: есть скрипт на php, который делает некоторые долгие операции с базой данных. Пользователь набирает его адрес в строке браузера, жмет Enter, и спокойно курит минут 30-40. Но хотелось бы чтобы он видел прогресс, хотелось бы выводить ему сообщения об операции по каждой позиции

[42 / 89300] Позиция #327 найдена, существует в системе, данные актуальны.<br/>
[43 / 89300] Позиция #21 найдена, существует в системе, данные актуальны.<br/>
[44 / 89300] Позиция #532 найдена, в системе не обнаружена, добавленна только что.<br/>

в таком духе.



Но тут возникает несколько вопросов, ответов на которые я не нашел.

1. Можно использовать flush в php для очистки буфера вывода, но Apache с gzip`ом все равно будет кешировать, как его отключать программно — представления не имею.
   
2. Если использовать AJAX, то я так понимаю колбек-функция заработает только когда все данные придут, как выводить тоже непонятно.
   

Может кто подсказать в какую сторону копать?

Answer 1

[Сергей Береснев]

Comet

Answer 2

[Антон]

Посмотрите в сторону dklabrealpolexor достаточно легкий comet-сервер.

Comments

[TheAlien]

Присоединяюсь.

[glebmachine]

Да, это очень крутая штука, на ней можно делать чудеса, чем и занимаюсь)

Answer 3

[Антон Пронин]

Я бы сделал так. Дополнительную страничку куда выводятся сообщения. т.е скрипт работает и пишет сообщения в базу или в файл как удобнее, а с этой страницы уже они отображаются. Потом делаю цикл из Ajax который забирает сообщения и выводит на экран.

Answer 4

[Kindman]

Можно попробовать использовать тег META REFRESH с интервалом в несколько секунд/минут

Comments

[Kindman]

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

Такой подход используется на некоторых WAP-ЧАТах,
и соответственно, наблюдать за процессом можно будет и с сотового телефона.
При этом сжатие г-зип позволит эффективно экономить трафик.

[Kindman]

Да, вот еще, забыл уточнить:
При переходе на страницы «истории» — эти страницы автоматически не рефрешутся.
То есть это позволит, перейдя на одну из предыдущих страниц, внимательно изучить ее содержимое.
И, еще можно сделать, чтобы на страницах «истории» выводилось не 10 событий, а, сразу, побольше: 50 или даже 100 (чтоб не приходилось долго листать).
Ну в завершении, кроме ссылок на отдельные страницы истории можно добавить ссылку на полную историю (а так же ссылку на zip-архив для быстрого скачивания всей истории вплоть до текущего среза).

[Kindman]

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

Answer 5

[Антон Корзунов]

Вы почти правы — нужен периодический flush на стороне сервера.
А как заставить сервер передавать ответы gzipнутыми кусочками?
Либо можно изменить content-type на такой который не будет ловиться апачем и не згипаться, либо просто попросить chunked вариант трансфера данных.

Answer 6

[Fastto]

Я бы лично организовал следующим образом:
1) Страница диспетчер — статическая, загружается быстро. По загрузке отправляет ajax-запрос на выполнение вашего долгоиграющего скрипта (или можно запрос отправить сабмитом в iframe)
2) Скрипт по ходу выполнения созданные сообщения складывает в очередь в таблицу бд или текстовый файл.
3) Со страницы диспетчера периодическим ajax-запросом получаем готовые новые сообщения из очереди.

Comments

[blazer]

поддерживаю. самое простое и логичное решение

Answer 7

[g00d]

Можно и вебсокеты использовать

Comments

[glebmachine]

Некроссбраузерно

Answer 8

[Wott]

flush не сильно поможет. Нужен отдельный протокол передачи сообщений — comet ли, websocket или ajax — вопрос десятый, главное как это сделать.

Для большого количества небольших операций типа загрузка в базу строк я просто делал ajax скриптом пакеты INSERT'ов — отмечал прогресс в клиенте и брал следующий блок в цикле. Такой подход требует дополнительных операций типа сохранение/восстановление контента последней операции, если она не удалась и корректного отката, и так далее.

Для длинных операций, типа запросов по сети, я делал фоновый процесс который брал из очереди задание и выполнял его. А клиент ajax-ом же просто отображал статус очереди.

Answer 9

[Borro]

Собственно только недавно промелькнул пост про WaterSpout — веб сервер для асинхронной передачи данных думаю это то, что вам нужно. Просто придется докрутить под себя.