[ Сообщений: 6 ] 
Начать новую тему Ответить на тему
Автор Сообщение
СообщениеДобавлено: 05 июл 2010, 23:31 
Аватара пользователя

Сообщения: 3
Поблагодарили: 0 раз.
Добрый день, форумчане. Интересует такой вопрос, кто-нибудь писал парсинг для разбора XML размером порядка 120М (примерное кол-во товаров 200000)? На форуме ничего подобного не встречал, максимум 25М и то по стандартной схеме занесения всего добра в массив.
На данный момент я написал парсер, он нормально обходит весь файл, но чем глубже тем медленней, плюс занесение 200000 тысяч записей или апдейтов идет медленно, в общем за 7 часов обработки файла, 3 раза переписанный скрипт смог обработать максимум 130000 заказов, хотелось бы все получать и хотя бы за 4 часа выгрузки:)
Кто может поделиться опытом? Пишу на ПХП под битрикс, но суть смогу понять на любом языке, если донесете.
Заранее спасибо.

ЗЫ хостинг обычный от зеноне, думаем о переезде на ВПС, но есть сомнения, что это увеличить производительность обработки в 4 раза.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 июл 2010, 04:05 
Аватара пользователя

Сообщения: 59
Поблагодарили: 5 раз.
Имел опыт обработки таких больших прайс-листов. ОБрабатывал достаточно быстро, но не секунды, так как все же к МайСкулу надо было много запросов делать к активным таблицам. Спасение было в том, чтобы формировать таблицу, которая будет потом будет вместо основной, то есть, данные вставлять в пустую, а потом ее переименовывать.
Но как время показало, я отказался от такой затеи и ушел в многократный разбор небольших прайсов, так как здесь есть свои плюсы, а именно: а) в случае сбоя, не обработается лишь текущий, а предыдущие и последующие, вероятно, будут с успехом закончены; б) нагрузка распределена по времени на большие срок, что дает возможность высвобождать ресурсы для WEB запросов и ответов, то есть, для меня лучше 10 раз повесить табличку (образно говоря) "на обслуживании" на 3 минуты, нежели один раз , но на полчаса.

Да, вот еще, не использую XML средства PHP для разбора прайс-листов.
Не гружу весь файл в ОП сервера, хотя мощность позволяет.
Не использую у хостера ВиртуалХостнг, использую Deticated сервер.
P.S. VPS миеня в свое время не спас. Точнее, на VPS все работало, но ресурсы капитально пожирались. Мне ничего не оставалось, как перейти на Deticated, о чем никогда потом не жалел.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 июл 2010, 10:38 
Сотрудник Миксмаркета
Аватара пользователя

Сообщения: 79
Поблагодарили: 1 раз.
1. Если еще не используете, то пора использовать SAX парсер, вместо DOM
2. Данные не обязательно сразу писать в mysql, гораздо быстрее складывать в файл, а потом один раз сделать LOAD DATA INFILE
3. Практика показала, что на php занесение добра в массив ни к чему доброму не приводит, поэтому на больших объемах данных лучше отказаться от такой схемы.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 июл 2010, 12:25 
Аватара пользователя

Сообщения: 3
Поблагодарили: 0 раз.
от DOM парсера отказался сразу, использовал XMLReader (на сколько знаю, он вроде SAX) , но в конце вообще товары стал обрабатывать руками, забирать по строчно и искать там <offer> производительность немного поднялась, SAX примерно так же и работает...
Идея с занесением всех команд MySQL в файл, а потом его выполнить приходила, но после 3 разов переписки парсинга и малой прибавки эффективность, появлялись сомнения:) за идею спасибо, наверное буду в 4 раз переписывать.
Других идей по ходу нету? Да и сам уже не знаю, что можно придумать.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 июл 2010, 16:42 
Аватара пользователя

Сообщения: 3
Поблагодарили: 0 раз.
Отпишусь, если кому-то в будущем понадобится. Самым узким местом, как все и предполагали был MySQL после добавления несколько десятков тысяч записей, скорость добавления падает на порядок и оптом снижается, а если делать апдейты записей, то это еще медленней. Решено было не писать в БД сразу, а записывать запросы к БД в файл, а после обработки всего XML сделать кроном развертку дампа через утилиту mysql. Так же из-за того, что хостинг обычный была проблема со временем работы скрипта, пришлось сделать поэтапную обработку, экспериментально получилось, что скрипт запущенный в кроне выполняется 5 минут, если больше иногда хостинг его "killed", поскольку парсер был написан руками, то с этим не было проблем: запустил отработал 5 минуты, сохранил позицию каретки в читаемом XML и закончил скрипт, крон выполняет следующий через 5 минут, пошагово все создается.
Итог:
обработка XML размером 125М и запись команд в файл идет порядка 1 часа, чаще быстрей, файл sql получается 100М
развертка этого 100М файла в БД занимает - 5 минут не больше.
Товаров получилось 217000

Тестировалось днем при нагрузках, ночью думаю будет все быстрей.
ВПС тоже попробовал (1000МГц 825М) настроен у хостеров оказался плохо, да и прибавки в производительности было очень мала, а если учесть что стоимость в 2 раза больше, то совсем не вариант.

Спасибо за идею с с записью запросов в файл, верней за толчек делать этот вариант:)

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 05 ноя 2010, 17:47 
Аватара пользователя

Сообщения: 22
Поблагодарили: 0 раз.
Я писал когда-то такой парсер. Ну не 120 мег, а 50Мб обрабатывал за секунды, практически не нагружая сервер.
напрямую преобразовывал xml в sql и все..

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему
 [ Сообщений: 6 ] 

   Похожие темы   Ответы   Автор   Просмотры   Последнее сообщение 
В этой теме нет новых непрочитанных сообщений. Проблемы парсинга больших XML-прайсов

в форуме Микс-Товары

13

Andrew

14257

04 фев 2007, 17:20

geosub Перейти к последнему сообщению



Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения
cron


О проекте Новости Пресса о нас Сотрудничество Вакансии Контакты
2005–2011 Партнерская сеть Миксмаркет
Разработка сайта — iji-design / AdLabs
Powered by phpBB Group