Меню
Что нового?

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

  • Автор темы Автор темы JamES
  • Дата начала Дата начала

JamES

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

Возможно ли это при стандартных настройках хостинга? Елсли да, то чем?
 
mani13 за ссылку спасибо, я имел ввиду под стандартными настройками - эти злостные 30 сек.

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

-~{}~ 13.06.06 00:15:

http://php5.bitflux.org/xml5_1/slide_57.php - о наглядная веСЧь
 
JamES
Ты ж наверняка не просто пробегаешь по файлу парсером, а выполняешь некую логику на каждой итерации. Вот и посчитай, за сколько пробегает в холостую и с твоей логикой.
 
я думаю не реально!
по крайней мере на php
используйте c/c++ и нормальную логику
 
EugeneVC
согласен, остается только это, на пхп серьезную работу никогда не нужно ссылать.
 
JamES

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

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

+ set_time_limit()
 
Ребята, вы что-то бредите.

Я только что специально сделал несколько тестов этого примера из мануала 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 МБ.

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

-~{}~ 13.06.06 14:17:

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

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

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

-~{}~ 13.06.06 17:51:

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