распарсить ~8mb XML за 30 сек

JamES

Новичок
распарсить ~8mb XML за 30 сек

Возможно ли это при стандартных настройках хостинга? Елсли да, то чем?
 

JamES

Новичок
mani13 за ссылку спасибо, я имел ввиду под стандартными настройками - эти злостные 30 сек.

Wicked - с мануалом знаком, я думаю это не стандартный вопрос по функциям.
вопрос заключается в решении задачи, возможно кто-нибудь встречался, если на форуме читатели спрашивали.
написал я парсер, используя DOM билиотеку - с временем справлялся, но жрал очень много памяти и апач подгружал до 100% проца
писал используя SAX увидел картину наоборот: много времени, мало памяти.
В качестве решения может может возможно читать XML по частям либо как-нибудь сохранять результат работы скрипта и его перезапускать через 30 сек

-~{}~ 13.06.06 00:15:

http://php5.bitflux.org/xml5_1/slide_57.php - о наглядная веСЧь
 

camka

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

EugeneVC

Новичок
я думаю не реально!
по крайней мере на php
используйте c/c++ и нормальную логику
 

JamES

Новичок
EugeneVC
согласен, остается только это, на пхп серьезную работу никогда не нужно ссылать.
 

Gorynych

Посетитель PHP-Клуба
JamES

ограничение в 30 секунд связано с пристреливанием скрипта по тайм-ауту, да?

если речь не о том, чтобы выполнить парсинг в режиме реального времени, в процессе присутсвия пользователя на странице (30 секунд ожидания наверное не лучший вариант), то почему бы не переложить обработку (парсинг) на фоновый процесс (скрипт) вызываемый по расписанию (доступ к crontab довольно стандартный вариант хостинга)?

+ set_time_limit()
 

Wicked

Новичок
Ребята, вы что-то бредите.

Я только что специально сделал несколько тестов этого примера из мануала XML Parser'а на разных xml-ках:
1) 64MB, 18570 xml-элементов, парсинг - 1.5 сек.
2) 6.9МБ, 5200 xml-элементов, парсинг - 0.35 сек.
3) 4.3МБ, 1220 xml-элементов, парсинг - 0.39 сек.
это показания тестов с пятой попытки, когда все дисковые операции уже закэшировались.

Тачка - цел 2400 / 512 МБ.

Так что у вас либо хостинг не быстрый, либо в самом скрипте тормоза.
 

DiTHER

bang bang
если это публичный хостинг, и возникают задачи парсить 8мб xml - то тут неувязка какая-то. Переходите на VPS что ли. Для парсинга - я бы на пхп этого не делал. Питон, си.

-~{}~ 13.06.06 14:17:

Wicked, попробуй сделать выборку XPath.
 

DiTHER

bang bang
ну вообще какая-то почва у человека же была когда он спрашивал про 8мб xml и 30 секунд :). Просто сам xml пропарсить, конечно быстрее. А вот повыбирать из него чего-нибудь (если не пользоваться ключами), то время в трубу улетает. Имхо, конечно.

Впрочем, действительно, мой пост не уместен. Не подумал.
 

JamES

Новичок
Wicked - данные бывают же различной вложенности и глубины. Так что эти тесты ни о чем не говорят.
с парсингом вопрос я решил.
Всем спасибо за внимание.
 

Wicked

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

Почему ты не хочешь поставить чистый эксперимент, запустив этот самый пример на твоем хостинге с твоим же файлом?

-~{}~ 13.06.06 17:51:

JamES
можно поинтересоваться, как именно решил?
 

JamES

Новичок
Wicked
конечно она не привносит никаких нагрузок, т.к. он выводит только структуру файла и ничего более, я имею ввиду запись данных в какую дин. структуру.
при выведении только структуры - 10.6 сек
при выведении структуры вместе с данными в броузер - 18.3 сек.
также хочу отметить большую нагрузку на проц. апачем 50%, еще не известно сколько он памяти займет, а на это тоже есть ограничения.
решил вопрос xmlreader-ом - как видно по статистике http://php5.bitflux.org/xml5_1/slide_57.php - лучше всех справляется с этой задачей.
пень 2.6/512 php 5.1.2
 
Сверху