проблема с echo большой переменной

[redic]

проблема с echo большой переменной

После xslt-преобразования, получается переменная размером примерно 200 килобайт. echo этой переменной занимает, иногда, больше 100 секунд.
Пример кода:

$start = microtime(true);
$xslt = new xsltProcessor();
$xslt->importStyleSheet(DomDocument::load($xslt_file));
$data = $xslt->transformToXML($doc->saveXML());
// время xslt
$xslt_time = microtime(true) - $start;

$start = microtime(true);
echo $data;
// время вывода
$xslt_echo_time = microtime(true) - $start;

В результате получается примерно такой расклад:

xslt_time=0.0485391616821 с.
xslt_echo_time=22.0413599014 с.
длина $data = 201677 байт

xslt_time=0.048369884491 с.
xslt_echo_time=9.92986392975 с.
длина $data = 201675 байт

но самое интересное, достаточно часто, время вывода остается в пределах 1 секунды, от чего зависит скорость в конкретном случае установить сложно. Загрузка сервера всегда примерно на одном уровне.

Посмотрел что скажет на это гугл, гугл сказал следующее:
http://answers.google.com/answers/threadview?id=731456
а вот тут http://wonko.com/article/299 человек дает некие рекомендации, мне однако разбиение на кусочки и потом вывод из массива особо не помогло - время вывода осталось таким же, да и количество тормозных страниц тоже.
Остается вариант только в записью переменной во временный файл и вывод всего файла, однако это извращение.
Может у кого есть более нормальное решение данной проблемы?

 

[tony2001]

output buffering = ?
какие-либо характеристики сервера известны, кроме загрузки?

-~{}~ 28.05.07 00:41:

а почему вы решили, что подфорум "Теория программирования" подходит для этого вопроса лучше всего? (просто интересно)

 

[redic]

output buffering?
То есть попробовать echo $data; через ob_start() - ob_end_flush()
спасибо попробую

Характеристики сервера известны все
dual xeon 3.0 ggz, 4 gb ram, freebsd 6.2, php 5.2.1, apache 1.3.37, Suhosin Patch 0.9.6.2, eAccelerator 0.9.5 - не знаю что именно Вам интересно, скажите, пожалуйста, какая характеристика нужна - я напишу

по поводу форума - я решил что "Теория программирования" подходит для этого вопроса лучше всего потому что, этот вопрос не связан с xml, хотя и возникает при косвенном участии xml+xslt, в этом подфоруме (пользуясь поиском перед созданием темы) я видел несколько похожих тем, однако вопросы в этих темах были другими, все это привело меня к мысли, что моя тема максимально удовлетворяет тематике именно этого подфорума.
Однако если я ошибаюсь, буду рад если Вы укажете на мою ошибку.

 

[Фанат]

http://phpclub.ru/talk/showthread.php?s=&threadid=71163&rand=0

 

[tony2001]

>output buffering?
>То есть попробовать echo $data; через ob_start() - ob_end_flush()
>спасибо попробую

да не за что.
вообще-то, я спрашивал включено оно или нет.

>eAccelerator 0.9.5

вот это сразу уберите.

 

[phprus]

tony2001

>eAccelerator 0.9.5
вот это сразу уберите.

Почему?

 

[redic]

Автор оригинала: tony2001
да не за что.
вообще-то, я спрашивал включено оно или нет.

выключено

Автор оригинала: tony2001
>eAccelerator 0.9.5
вот это сразу уберите.

присоединяюсь к предыдущему оратору - почему?

 

[Фанат]

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

phprus
не пробовал читать правила составления багрепортов на багс.пхп.нет?

 

[tony2001]

phprus
нельзя стать ученым без публикаций. нельзя писать модуль для ядра и при этом в разработке ядра не участвовать.
я так понимаю, что это просто Turck MMCache с костылями для PHP5, ничего хорошего от него ожидать не приходится.

redic
если просто выводить 200K текстовый файл - то же самое?
что если включить output buffering?
что если обновить PHP до 5.2.2 (и очень желательно чистый, без всяких псевдо-секьюрных патчей) ?

 

[phprus]

Фанат

не пробовал читать правила составления багрепортов на багс.пхп.нет?

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

я так понимаю, что это просто Turck MMCache с костылями для PHP5, ничего хорошего от него ожидать не приходится.

А есть ли тогда альтернативные модули с такой-же функциональностью как у eAccelerator, но для php5.2 ?

 

[tony2001]

APC ?
он, по крайней мере, активно поддерживается и используется (в Yahoo!).

 

[redic]

Автор оригинала: tony2001
если просто выводить 200K текстовый файл - то же самое?
что если включить output buffering?
что если обновить PHP до 5.2.2 (и очень желательно чистый, без всяких псевдо-секьюрных патчей) ?

Погонял срипт на другом сервере - Gentoo там Apache 2.0, PHP 5.2.2 "без всяких псевдо-секьюрных патчей", но с eAccelerator 0.9.5.1 (отключение оного на двух сервера положительного эффекта не дает ), примерно тоже самое.
Использование текстовых файлов тоже ничего особо не дало, количество тормозных страниц вроде снизилось, но не очень сильно.
а вот output buffering вроде решило проблему, во всяком случае за час тормозных страниц не было.
Насчет eAccelerator или APC - вопрос не по теме, да и как мне кажется, уже давно перешел в разряд святых камней преткновения.
Думаю стоит попробовать APC, но пока не до этого

-~{}~ 29.05.07 00:26:

уже можно сказать однозначно - output buffering помог, спасибо tony2001
однако вот в чем вопрос, так как подсчет времени выполнения вывода происходит не в процесса самой передачи данных клиенту, а наполнении буфера, не может ли быть так, что итоговая передача буфера клиенту будет занимать долгое время?
Какое средство Вы можете посоветовать для контроля таких показателей?

 

[grigori]

однако вот в чем вопрос, так как подсчет времени выполнения вывода происходит не в процесса самой передачи данных клиенту, а наполнении буфера, не может ли быть так, что итоговая передача буфера клиенту будет занимать долгое время?
Какое средство Вы можете посоветовать для контроля таких показателей?

По-видимому, проблема именно связана со временем передачи данных.
При выводе echo может ждать доступности tcp-буфера для записи, и если скорость низкая - может показаться, что скрипт работает долго. Поэтому, если открыть и держать 300+ соединений с веб-сайтом, который работает под апачем со стандартной конфигурацией - сервер станет недоступен.
Скорость работы скрипта надо измерять без задержек связи - на localhost, например.
Если медленных клиентов много - есть смысл заменить апач на nginx/lighttpd (c кешем) + php-fcgi