[ Сообщений: 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

16073

04 фев 2007, 17:20

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



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


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