Большой объем скрипта в ИЕ7

[dimagolov]

Большой объем скрипта в ИЕ7

У меня отдаются данные с сервера на клиента через iframe. Данных много (расчитано на локалку), то есть массив с ними большой (около 12 тыс. записей). Общий размер html-я с объявлением этого массива примерно 2-3 Мб.
Обнаружил такую засаду: В ИЕ7 на размере чуть больше 1.5Мб интерпретатор дает Syntax Error. Если я коментарю строчки, на которых он находит ошибку, то строка с ошибкой смещается на первую незакоментаренную, которая после "границы", то есть не важно какая строка, важно, что после определенного объема скрипта.
Кто-то с таким сталкивался?

п.с. У ИЕ6 таких проблем нету, прекрасно поедает такие массивы.

-~{}~ 06.02.08 19:19:

покопался еще и выяснил, что проблема скорее всего в объеме тага <script>. Если его закончить до критической точки и опять открыть, то ИЕ7 прекрасно все отрабатывает.

 

[fast2111]

А если сделать так <script>eval(" .... 2mb .... ");</script> интересно что будет. Как здесь поведет себя eval, отработает ли....
Извини за флуд

 

[dimagolov]

fast2111, отнюдь не флуд
eval уже пройденный этап, так как изначально брал через ajax-json, а он как известно конвертит eval-ом. так вот, при размере данных до метра (которые iframe + интерпретатор обрабатывают за пару секунд) eval json-а происходил пару-тройку минут при полной загрузке проца клиента, то есть на 2 порядка медленне.
а ответ на твой вопрос прост: так как у ИЕ7 проблема с размером содержимого тега <script>, то результат что с eval-ом, что без него для 2-х метров будет одинаков: Syntax Error.

п.с. еще обнаружил, что если не делать ob_start, то скрипт выполняется столько, сколько клиент забирает данные. то есть при заполнении буфера (апача?) из-за того, что клиент не успевает забрать такой объем скрипт стоит и ждет, не выполняя очередное echo пока клиент не вычитает данные. как только пукается ob_start то скрипт сразу выпуливает все содержимое, а уже php разбирается с апачем на тему когда и сколько чего отдать (Apache 2.2 Win32). Реально (без буферизации) скрипт у меня отдавал эти 2 метра от 10 до 20 секунд (ровно столько, сколько клиент ее загружал), с буферизацией - около 1-й секунды (сам запрос к базе выполняется за 0.1сек.). Ну а если включать gzip буфера, то клиент грузит такой объем за 3-5 секунд (сетка WiFi).

 

[maxwell]

ЖабоСкрипт славится своей утечкой памяти.
Я бы еще раза 3-4 подумал прежде чем такие обьемы данных через броузер грузить.

 

[dark-demon]

> ЖабоСкрипт славится своей утечкой памяти.

разве что среди людей, которые не в теме..

 

[dimagolov]

maxwell
конструктивные предложения (кроме того, что перестать разрабатывать веб-приложения) имеются?

 

[IIIEPJIOK]

а не смотрели, что будет если js отдельным файлом подгружать?

 

[fast2111]

dimagolov я толком не понимаю какую проблему ты решаешь, но надеюсь это тебе поможет да и нетолько тебе
http://en.wikipedia.org/wiki/Comet_(programming)
http://www.zeitoun.net/index.php?2007/06/22/46-how-to-implement-comet-with-php
тем более что локалка, да и сервером что угодно можешь сделать...

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

 

[dimagolov]

fast2111, да уже никто не надрывается
комет это прикольно, но система уже имеет архитектуру и пытаться втулить что-то новое в нее по идее будет сложнее, чем пользовать то, что уже есть, тем более, что производительности и пропускной способности хватает для таких объемов.
бага которая была с ИЕ7 замечательно решилась буферизацией + разрезанием тега <script> (а на всякий пожарный скидываю буфер и вставляю конец-начало <script> если размер буфера превысил 512К, так за одно и меньше памяти пхп нужно на хранение буфера). то есть ИЕ7 не только создал проблемы, но и заставил соптимизировать код который отвечал за буферизацию и вывод данных. просто раньше с такими объемами не работали и не заморачивались на это, а вот как возникла проблема, так и пришлось искать адекатное решение. мне кажется, что решение вполне адекватное.

про задачу. сейчас такие объемы гоняються чтобы отбирать содержимое каскадных фильтров. если запрос идет по всей базе (а не по отдельным ее частям), то запрос-то отрабатывает быстро (индексы), а вот данных получается много. но прикол в том, что по частям они не особо интересны - их надо показать в дроп-дауне, делать по ним type-ahead, etc, и в общем без разницы одним ответом их отдать или несколькими - пользоваться ими можно будет только когда соберется все и если отдавать по частям то только будет гемор их собирать вместе (то есть на определенном этапе это удвоит объем юзаемой JS-ом памяти).

комет хорош когда надо дополнять данные на клиенте новыми и делать это независимо от клиента (хотя чем это особо лучше аякс-запросов по таймеру я не понимаю)

 

[fast2111]

понятно... и даже страшно представить эту "страничку".

чем это особо лучше аякс-запросов по таймеру я не понимаю

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

 

[dimagolov]

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

это все понятно. мне не понятно чем это лучше setInterval (function PullData () { }, 3000); То есть недостатков я вижу немало (да хоть не совсем стандартное http соединение, которое требует дополнительных модулей на сервере, либы для работы с ним и т.п.), а вот преимущество только одно: если данные надо отдавать клиенту не каждые 3 секунды а через случайные интервалы времени, причем много большие, чем максимально допустимое время задержки передачи на клиента, то без комета результативных запросов будет много меньше холостых, а с ним все будет результативными. только вот надо ли оно и когда у меня встанет такая задача, с таким распределениям тайминга я представить не могу.