"По поводу многопоточных парсеров - а зачем их делать многопоточными?"
1. задач много, желательно выполнять согласованно в рамках одного приложения
2. ядер много, оперативки много, зачем разбивать согласованное приложение на кучу отдельных скриптов - теряется профит.
3. иногда нужно именно многопоточно
4. оверхед на каждый скрипт - это плохо, ресурсы ведь не бесплатные
"Да и не знаю откуда вы взяли информацию о гигобайтных файлах"
Это был пример реального xml файла с книжками и попробуйте найти PHP решение под него в интернете - много горе-php программистов жалуются что пришлось переписать на Си что бы это работало:)
Я просто не считаю что 1+ гигабайт на файл это много, вовсе нет, это очень даже не много. Теперь представим что этот 1+гигабайт xml это не файл - а часть данных доступных по некоторому API... и становится интересно и под профиль топикпастера тоже похоже.
"Опять же только у ерланга из коробки идет мягкое подение, и то я с ним не работал (хотя в планах)."
Перешёл на Golang, там defer recover механизм работающий отлично.
"В PHP7 например большую часть фаталов уже превратили в исключения, так что проблем с контролем ошибок не сильно много нынче."
Окей, произошло исключение - что делать в таком случае? Вешать обработчики исключений по всему коду пытаясь предугадать где бомбанёт или сделать единый обработчик который перезапустит скрипт? И то и то не так что бы сильно удобно, да и оверхед этих исключений приличный.
Сергей Протько: "Про падение скриптов не совсем понял, в следствии ошибок вашей программы? Да как бы... ". Нет речь о том что GC не удаляет достаточно данных в нужный момент и выделенной скрипту памяти не хватает для работы на длинных дистанциях. Может упасть, а может и не упасть и когда упадёт - заранее не известно.
Сергей Протько: supervisord есть далеко не у каждого клиента, было бы хорошо если бы это можно было делать в самом приложении (демоне).
Что именно не актуально уже пять лет? Падение скриптов? Да ладно. Мне вот серьёзно хочется узнать что у вас за задачи для демонов которые по пол года живут и не умирают, видимо железа много и фаза луны совпадает. Я хочу так - мало ресурсов = медленно работает, много ресурсов = быстро работает, при этом ни в том ни в том варианте падать не должно, умирать от нехватки памяти тоже.
Про быстроту можно много бенч-марков делать... но как-то многопоточные парсеры на нём смешными выходят. Тот же simple_html_dom помноженный на множество запросов не печёт данные как горячие пирожки, скорее не торопливо ходит за ними в магазин.
К тому же топик-пастер явно указал на "большой объём информации". Например xml на 3.7 гигабайта от ozon.ru парсить.... или ещё чего-нить в таком духе.
Чего не сделаешь что бы юзать PHP для такой задачи:) А вот причины:
1. не высвобождаются ресурсы (память, дескрипторы) в нужный момент - можно попробовать запускать GC после каждой итерации или после группы итераций, но однажды такой скрипт всё равно упадёт.
2. если скрипт падает - подхватить и восстановить без дополнительных костылей не получится
3. общая низкая производительность на каждую итерацию
Bowen: так это разные задачи. Вы хотите комбайн чтоли?
1. для удаления некоторых тегов - сделайте метод который принимает obj_id, obj_type, tag_id и удаляет то что нужно
2. для удаления всех тегов для объекта - obj_id, obj_type
И всё...
Пума Тайланд: вы предположили что я кричу?:) Вернули временно и к вопросу о серверах это никак не относится:) Так же стоит понять что "уменьшение функционала" не должно равняться "увеличению серверного парка", для таких компаний как Яндекс уж точно.
А между тем - у нас хорошая погода, листопад и вообще, мы к кулинарному фестивалю готовимся:)
Получил сообщение 13 октября: "Подскажите, как вы планируете использовать API и для какого ресурса? У нас есть несколько вариантов набора данных, которые мы можем передавать. В зависимости от задачи, которую вы хотите решить, мы сможем предоставить вам наиболее полный набор данных."
По своим задачам отписался, интересно что предлагают другим.
Лично мне доступ к API только что бы посмотреть и может что интересное найти. Например для выгрузки данных о фильме, об актёре, то что с сайта убрали, к примеру... Если API будет дублировать полный функционал по данным обычного старого сайта - то будет отлично и с этим можно будет спокойно работать.
Оценку конкретного фильма можно было и раньше по xml получать совершенно свободно. Хоть это они ещё не убили: rating.kinopoisk.ru/737843.gif rating.kinopoisk.ru/737843.xml
Раньше там было два значение: количество оценок и финальный рейтинг. Теперь количество оценок убрали, а саму кнопку перерисовали под новый дизайн. Удивлён что этот механизм не посеять умудрились.
Пума Тайланд: почему глупо-то? Я более чем уверен что то API что было до этого (разное и не для всех) убито вместе с сайтом как и многие сервисы которые пока не бросаются в глаза. У ребят было два года что бы решить что делать и как делать, а потом сделать.
Пума Тайланд: я делал предыдущую (теперь её называют старой) версию сайта, новую команду тоже видел, я ждал большего, хотя фейл и был очевиден, но что бы на столько:) А баги выкатываются примерно так:
1. нашли баг
2. прошло две недели - задача отправилась на разработку
3. задача сделана за 15минут - 2-3 часа
4. задача месяц-два не может уехать в тестинг
5. задача уехала в тестинг... после тестинга ждёт попадания в общий мердж
Но это от команды к команде разное. Мнение об API у меня не изменилось - оно или есть или его нет.
Это нельзя назвать открытым API. В недрах Яндекса когда почта идёт "нужен доступ к API такому-то такому-то туда-то туда-то" всё выделяется (включается) минут за 15-20 если человек получил письмо. С внешним миром так не работают - нельзя назвать что-то открытое и не дать:)
FireGM: по сути вы утвердительно ответили на мой вопрос. Что будет если все начнут придерживаться такой идеологии и требовать наличия gin... надеюсь вы хотя бы оставили возможность его полного отсутствия в реальном пакете?:) Впрочем, наверное скорее да, чем нет.
FireGM: ну прямо смешно:) Для вас наверное всё велосипеды - может вам не стоит работать программистом тогда?:) Берите уже готовое, составляйте кирпичики - будьте строителем, что уж там:) У вас тут нет ни повода ни задачи - делать велосипед.