Параллельный импорт данных

[aleks_raiden]

почему бы не использовать для этого специальные инструменты — gearmand

[tushev]

Не всегда есть возможность установить заказчику «правильное решение». Иногда все приходится решать на голом PHP.

А еще я полагаю, что если никто не будет изобретать усовершенствованные велосипеды, в нашем мире не будет появляться ничего нового. Так и будем все делать, на «старом и проверенном».

[Lemoor]

Согласен. Не так давно пришлось писать свою реализацию БД на голом PHP. Извращение? А это ведь было условие, обязательное к выполнению.

[fantaseour]

это где это VPS за 300р/мес?

если пройти мимо скидок при покупке на год, то стоить будет 1000р. Народ жмется, правда.

[Vit228]

не сочтите за рекламу
я от «шаред» отказался в пользу vds от 1гб. ру
пока доволен.

[fantaseour]

интересно почему сильно различаются праметры OpenVZ и Hyper-V?

я сижу на виртуоззо и что-то получается даже 1500р в мес. Мелколавочного клиента на такое трудно уговорить. А на 300-400р вполне можно.

[fantaseour]

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

[m00t]

Есть шаред хостинг за 10$, все рюшечки имеются — вплоть до SSH. Есть VDS за 20-30$ или около того (64 оперативки, 400 проц) от ПервыхВДС. И есть веб-приложение на Zend Framework. На шареде летает. На VDS — 3-4 сек генерация страницы. Чтобы на ВДС тоже работало нормально, нужно купить далеко не за 20-30$ сервер.
Я не говорю про нагрузки от большого количества посетителей — это отдельная тема.

[m00t]

Я к тому, что дешевый VDS != шаред + root access в общем случае.

[tester_9]

Эта статья помогла мне решить одну из проблем. Спасибо.
В модифицированном виде использую как задачу. Возвращаясь к многозадачности на PHP
Правда выяснилась неприятная неожиданность — обычно из-за настроек сервера нельзя качать более 1000 файлов одновременно.

[krestjaninoff]

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

[tushev]

Согласен. Gearman неплох если делаешь сеть краулеров а-ля гугл на нескольких разных физических машинах или даже датацентрах. Когда много разного ПО… А тут автор предложил простенький RSS грабер на несколько десятков источников, и поразмышлял, как бы это поудобнее и попроще реализовать.

Только вот последнее время на хабре у комментаторов пошла тенденция «стрелять из пушки по воробьям». И если вы пытаетесь решить простую задачу простым способом, то вас могут обозвать дилетантом.

[crocodile2u]

А можно сравнение со stream_select? В плане удобства использования в основном…

[kashey]

Имхо правильный вариант — форкать некий универсальный контролер, который далее к тебе приконектиться, а ты ему по сокету передашь нужную информацию, в том числе и более сложную чем просто номер фида…

[Quiz]

Будет над чем подумать, спасибо.
Одна из задач, в которую я в последнее время упёрся — реализация пусть медленного, но «лёгкого» многопоточного краулера для одного из проектов.
Когда допилю его, надо будет статейку на Хабре награфоманить. =)
Что касается велосипедов, о которых очень часто пишут в таких случаях — иногда от них не удаётся уйти. Это касается, в основном, нетривиальных задач в системах, построенных на нечёткой логике.

[m00t]

ИМХО, проблема немного надумана. Первый пример с мультикурлом — ждем выполнения _всех_ загрузок, только потом их обрабатываем. Почему бы не обрабатывать каждую ленту сразу после ее загрузки? Т.е. поставили на загрузку 10, одна из них загрузилась, еще девять грузятся. В это время мы вполне ее успеем распарсить и сложить как надо в базу. Очень редко у меня многопоточный граббер упирался в своей роизводительности в роцессор и mySQL — как правило именно загрузка контента является самым узким местом. Ну так давайте параллелить только ее? Благо мультикурл прекрасно справляется с такой задачей.

[tushev]

Мне кажется, что во многих случаях удобно разделить грабер и обработчик.
Есть список URL-ов в БД. Грабер берет очередную порцию URL-ов, и в несколько потоков выкачивает их, загружает сырой результат в ту же БД. Затем берет следующую порцию и т.д.
Совершенно независимо, параллельно с этим работает обработчик (парсер). Когда в базе появляются новые сырые данные он начинает их обрабатывать уже по очереди. Возможно этот обработчик сам добавляет новые URL-лы для грабера, например если это краулер.

[symbix]

Забыт еще один способ — самостоятельное мультиплексирование. Раскладывается, собственно, на два варианта: 1) socket_select/stream_select, 2) pecl/libevent — если надо обрабатывать действительно большое количество параллельных запросов.

[nfx]

Для одного проекта занимался паралельной обработкой 200к записей. Работа с несколькими АРІ одновременно. Были свои подводные камни. Построение на основе Dependency Injection не раз спасало. Может как-то написать об етом топик.

[m00t]

Можно узнать, какое отношение DI имеет к параллельной обработке данных?

[egorinsk]

Ненавижу названия функций типа doImport(). Что за фигня? чем она отличается от import()?

[dzugaru]

Семантикой )