Как во время работы скрипта постепенно выводить результаты

понтам тут не место, это не сцена :)

а иаду глотнете именно вы, если жестко в пхпини запретят эту функцию или выставят жесткое ограничение на исполнение скрипта админы ;)

кстти весь понт по поводу set_time_limit

ты не понимаешь, что это за функция (flush), если считаешь что её специально запрещают. она наоборот им повышает производительность очищая буфер вывода результатов скрипта. тебы послушать, так вообще в пхп надо только операторами пользоваться)

а ограничение на выполнение могут и на скрипт, который аякс дёргает, наложить.

на таких хостингах сидят только мазахисты.

set_time_limit понятно что 0, иначе скрипт не рабочий в любом случае!

get-names.com, да вот не в любом ... set_time_limit не ограничивает время таких операция как curl_exec. к примеру (это еще одну преимущество перед гавносокетами). а если человек 30 секунд обрабатывает хтмл страницу, то это ненормально (в этом месте я бы обозвался некрасивыми словами).

запрещают не flush это во первых, а set_time_imit (ну не запрещают, а она просто не работает).

во вторых flush нисколько не помогает, почитай сынок про буферизацию и не спорь с папками ;)

угу, а процесс висит. А давайте таких 10 запустим, а 100, а 1000 - пусть все помогают? :) А в каждом соединение с mysql откроем, чтобы помочь ещё больше.

Как скрипт может отработать до конца, если он постоянно грохается системой по таймауту? Нет... я, конечно, вижу выход с сохранениями параметров и повторным стартом скрипта с места креша, но это, действительно, мазахизм. По-моему использование flush есть единственный разумный вариант. - выглядит приблизительно вот так (писал около года назад для темы из этой ветки)...

P.S. и, кстаи, аяксом предпологается каждый раз запускать новую версию скрипта или запрашивать его состояние?

тогда скажи в какой из обсуждаемых слачаев (аяксом или с flush) скрипт будет правильно работать без set_time_limit равного 0. конечно можно запускать последовательно аяксом до достижения нужного результата, но большее извращение и придумать сложно, когда вместо этого можно задать всего лишь одну директиву.

и вообще не путай понятия скрипт и оператор! я писал именно про скрипт.

запущенные curl_exec пусть и отработает, а толку от них при парсинге страниц? надо ведь ещё и разбор сделать.

мне казалось любому понятно, что c пустым кешем работается быстрее, чем с забитым. видно это не так :(

в обоих способах реализации число процессов будет одинаково. ток с flush в кеше вывода будет меньше данных. думаю, параллельно сможет работать больше процессов с flush, чем без него.

Мне кажется, данных в первом посте недостаточно, надо видеть реальные цифры, чего сколько обрабатывается, где это все должно работать и т.д. Решение задачи, поставленной "в общем виде", редко оказывается оптимальным в боевых условиях.

Мой вариант, что-то похожее использовалось в одном из наших проектов:

1. Код, который что-то долго и муторно делает, отделяем от веб-сервера, пусть живет отдельной жизнью. Это может быть демон, крутящий бесконечный цикл, запись в кроне и т.д. Избавившись от привязки к веб-серверу, мы, к примеру, можем использовать fork() для распределения объема работы между несколькими процессами.

2. Служебный код начинает реально работать, получив некоторое "задание". Пользователь через GUI ничего не запускает, он лишь добавляет "задание" в хранилище (например, в БД).

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

4. Если уж пользователю так интересно, как идут дела, мы формируем для него отдельный GUI, где раз в N секунд через AJAX запрашивается отдельный скрипт, умеющий визуально отображать состояние "задания". В данном случае мы можем показать число обработанных страниц и число страниц, поставленных в очередь в настоящий момент.

Очевидный профит - в независимости "служебного" кода от клиента. Пользователь может закрыть браузер, а потом открыть снова, это никак не скажется на работе. Более того, за выполнением работы могут одновременно наблюдать несколько разных пользователей. При этом "служебный" код только делает свою работу и не парится о том, что кому как отображать, т.е. "дизайновую" часть мы полностью отделяем.

На шаред-хостинге реализовать такую схему едва ли возможно.

Решение с flush() может проканать для очень простых и "коротких" задачек.

get-names.com, ты безопытен что пипец, а еще умничаешь ... прекращай, и пистуй в гугль читать чтотебе советуют

bearman, то что ты сверх некомпетентен видно сразу.

хватило даже того, что ТС написал, что скрип у него работает, но долго, и надо сделать вывод красиво, а ты тут начал писать про set_time_limit)))))

и до не нормативной лексики я, в отличия от тебя, опускаться не собираюсь.

профессионалам здесь в общем всё понятно, а у тебе ни одного поста в тему.

get-names.com, ок. надеюсь тебе морду сегодня кто нить набьет :)

bearman добавил 17.11.2009 в 09:57

если набьет кто нить, отпишись, ПРОФЕССИОНАЛ!