Зачем PPS-системы выдают свои фиды не в стандартном XML

Зачем PPS-системы выдают свои фиды не в стандартном XML, который парсить станндартными инструментами, а сочиняют каждый свое программистское счастье?

наверное, потому что не все родились программерами

Sterx писал:

наверное, потому что не все родились программерами

5 балов

Sterx писал:

наверное, потому что не все родились программерами

программистами не рождаются - это последствия родовой травмы

ну спасибо Вад

Потому что
1. На большом трафе надо заботиться не о "стандартных средствах", а о меньшей нагрузке.
2. О средствах парсинга фида заботиться вообще не надо, поскольку скрипт парсинга поставляется вместе с фидом.
3. Парсить массив данных с разделителями проще, чем парсить xml

Таким образом, применение xml-фида я лично считаю совершенно неоправданым и излишним в данном случае.

Xrenoder писал:

Потому что 1. На большом трафе надо заботиться не о "стандартных средствах", а о меньшей нагрузке. 2. О средствах парсинга фида заботиться вообще не надо, поскольку скрипт парсинга поставляется вместе с фидом. 3. Парсить массив данных с разделителями проще, чем парсить xml

1. Какая разница в смысле нагрузки на сервер в том, в каком формате идут выдаваемые данные? Ты всего лишь делаешь некий запрос к базе, форматируешь то, что она выдает и выплевываешь результат клиенту. Кода написано уже столько для XML, что выдумывать ничего нового не надо - причем не только на php/perl, но и на куда более шустрых языках.
2. А если стандартный кого не устраивает? В том и плюс xml, что ты получаешь данные в стандартных форматах и сам решаешь, как ты их будешь обрабатывать.
3. А это кому как Если у тебя, к примеру, в данных попадаются символы разделителя, которые тебе приходися экранировать - то задача становится менее тривиальной, чем простой split(). Ну, у perl'а всяких модулей полно - а если не на perl писать? Вообще можно и варианты на выбор предоставлять, это ж всего лишь фронт-енд к данным

Хреновелосипедостроитель )))

XML технологии рулят.

Тпру....

А кто это не дает XML ?
Умакс
MakeThemCry
Ренго
Клик
точно дают.

Кто НЕ дает ?

SEP по дефолту по-моему отдает в тексте а не в XML
правда я юзаю все равно выдачу в формате Уни

Xrenoder писал:

Потому что 1. На большом трафе надо заботиться не о "стандартных средствах", а о меньшей нагрузке. 2. О средствах парсинга фида заботиться вообще не надо, поскольку скрипт парсинга поставляется вместе с фидом. 3. Парсить массив данных с разделителями проще, чем парсить xml Таким образом, применение xml-фида я лично считаю совершенно неоправданым и излишним в данном случае.

солидарен,
парсинг XML, и вообще парсинг, забирает уйму ресурсов,
кроме того использование XML для результатов поиска это перебор.

begemot, не нравится стандартный парсер XML для php/perl (да, не спорю, он не быстрый) - кто тебе мешает парсить фид регулярками стандартными?

мешает отсутствие дурки в голове и надеюсь всегда будет мешать

ps: как вообще может возникать такой вопрос ?

begemot писал:

солидарен, парсинг XML, и вообще парсинг, забирает уйму ресурсов, кроме того использование XML для результатов поиска это перебор.

Хех... С чего начали, и чем закончили... %)

Не нравится XML - так текстовый фид (тот, что "с разделителями") тоже у многих есть.

Да и вобще, чего вы паритесь ? Сколько надо поисков, что-бы парсинг дал заметную нагрузку ? Даже при самой дубовй реализации - сколько их надо что-бы загрузить плохонький дедик (цел2000/1гиг/..) ? И сколько это принесет ? Чесслово, стоимость дедика, в этой сумме, просто не заметна.

Sams: 200-300к серчей убьет твой целерон в считанные минуты....

DE писал:

Sams: 200-300к серчей убьет твой целерон в считанные минуты....

Ну давай посчитаем... 200к серчей~=20к кликов~=(при самом дерьмовом раскладе) 0.03*20000=$600 в день=$18000 в месяц, или (при нормальном) 0.2*20000=$4000 в день, = $120000 в мес. Так ? И ты хочешь сказать, что для разделения нагрузки тебе будет "слишком дорого" взять 2-ой сервак (за 100-300 баков) ? Так стоит-ли изгаляться с нестандартными фидами/скриптами, постоянно их правя, доделывая и т.д. (потому как х.з. что захочется вписать в титл или деск очередному рекламодателю, или какая новыя фичи/даныые появятся в фиде) ради уменьшения затрат максимум на 1% ?

И потом, это как-же надо писать что-бы именно парсинг (а не запрос фида, обработка реврайтов и дени, ...) давал бОльшую нагрузку ?

Как минимум могу привести 4 момента:
1. Sams, нагрузка на сервер в течении дня неравномерная. А еще чаще, бывают ситуации, когда придут к тебе на сервер несколько ботов одновременно, сделают сотню реквестов в секунду и считай что сдох сервак. Так что бывает что даже незначительная экономия ресурсов оказывается критичной для работы сервера.

2. ХМЛ - это жесткий стандарт чуствительный к ошибкам. В случае если по каким-то причинам ХМЛ файл не загрузился до конца, или в нем есть ошибки ты не получишь результатов вообще.

3. Сам стандарт ХМЛ подразумевает что для передачи любой информации потребуется создание файла раза в 3 большего чем сам обьем передаваемой полезной информации. Т.е. считай твой сервак, и сервак который отдает фид жрет в 3 раза больше трафа чем надо.

4. Когда я делал автофид, столкнулся с тем, что на многих крупных хостинг компаниях по дефолту ХМЛ не поддерживается, т.е. надо или пересобирать РНР (невсем доступно) или делать собственный парсер (а в чем тогда смысл ? ;)). Кстати фиды некоторых РРС, построенные на стандартных функциях ХМЛ - на таких серваках не работают вообще.

Остальное вроде сказали уже

bog писал:

Как минимум могу привести 4 момента: 1. Sams, нагрузка на сервер в течении дня неравномерная. А еще чаще, бывают ситуации, когда придут к тебе на сервер несколько ботов одновременно, сделают сотню реквестов в секунду и считай что сдох сервак. Так что бывает что даже незначительная экономия ресурсов оказывается критичной для работы сервера.

При большой нагрузке именно от ботов, для них лучше держать "закешированный" ответ (с измененными клик-линками, чтоб правил не нарушать). Это дает еще и несколько плюсов (в т.ч. по деньгам).

bog писал:

2. ХМЛ - это жесткий стандарт чуствительный к ошибкам. В случае если по каким-то причинам ХМЛ файл не загрузился до конца, или в нем есть ошибки ты не получишь результатов вообще.

Это как-бы да. Хотя ... а зачем мне результат с ошибками ?

bog писал:

3. Сам стандарт ХМЛ подразумевает что для передачи любой информации потребуется создание файла раза в 3 большего чем сам обьем передаваемой полезной информации. Т.е. считай твой сервак, и сервак который отдает фид жрет в 3 раза больше трафа чем надо.

И сколько того трафу ? Выдача морды фида (особенно если с графикой) сьедает в разы больше. (А твой "автофид" просто умножает этот траф на кол-во ППС ;) Но т.к. это окупается, видимо, более высокими бидами - ни кто на это не жалуется. Так ? )

bog писал:

4. Когда я делал автофид, столкнулся с тем, что на многих крупных хостинг компаниях по дефолту ХМЛ не поддерживается, т.е. надо или пересобирать РНР (невсем доступно) или делать собственный парсер (а в чем тогда смысл ? ;)). Кстати фиды некоторых РРС, построенные на стандартных функциях ХМЛ - на таких серваках не работают вообще.

Хм.. Возможно. Хотя лично я еще не встречал таких хостингов.

Цитата:

И сколько того трафу ? Выдача морды фида (особенно если с графикой) сьедает в разы больше.

у нас на одном из сервачков, под фидом, входящий трафик практически равен исходящему, разница в 15%

bog писал:

Как минимум могу привести 4 момента: 1. Sams, нагрузка на сервер в течении дня неравномерная. А еще чаще, бывают ситуации, когда придут к тебе на сервер несколько ботов одновременно, сделают сотню реквестов в секунду и считай что сдох сервак. Так что бывает что даже незначительная экономия ресурсов оказывается критичной для работы сервера.

И вот ведь что интересно - убьют сервак не слайсы CPU, поеденные выдачей XML или CSV (без разницы) - убьет его количество запросов к базе :) Диск-то по определению на многие порядки медленнее CPU/памяти. То есть вообще-то это решается созданием connection pool с ограниченным количеством коннекций к базе, кэшированием результатов, и т.п. - немножко на другом уровне. При чем тут XML vs CSV?

Вставлю свои пять копеек:
по моему опыту разборки различных фидов мне проще было всегда там где нет xml а был простой CSV, считаю что CSV обработать проще, быстрее и ресурсов это заберет меньше.
Хотя каждому свое, потому лучше было бы если предлагали 2 вида на любителя xml & csv.
А по поводу трафика, это да xml фид ест его в несколько раз больше чем хотелось бы...

фиды - не та область где необходим xml . csv файл распарсить гораздо быстрее, + съкономленный траффик.
А потом не надо забывать, что xml парсеры сами по себе так же требуют память.

Dr.Syshalt писал:

И вот ведь что интересно - убьют сервак не слайсы CPU, поеденные выдачей XML или CSV (без разницы) - убьет его количество запросов к базе

Э... это вы о чем вообще ?
Во первых я говорю о конечных вебмастерах.
Во вторых, ты думаешь что кто то из РРС с которыми ты работаешь берет результаты из своей базы ? ;)
Так я тебя разочарую, все они так же являются просто реселерами более крупных РРС, и соответственно также получают от них фид. (кстати в xml\wsl формате. Который крупные РРС используют не потому что это лучше, а потому что это стандарт индустрии, и есть стандартные кроссплатформенные решения для его обработки).

Sams писал:

При большой нагрузке именно от ботов, для них лучше держать "закешированный" ответ (с измененными клик-линками, чтоб правил не нарушать). Это дает еще и несколько плюсов (в т.ч. по деньгам)..

1. как отличить бота от пользователя ;) боты они знаешь ли разные бывают, а не только с юзерагентом гуглбот
2. в стандартных скриптах такие возможности не предусматриваются, так что о чем речь ? А то если теоретизировать, то можно все данные гзипом упаковывать, а вместо ХМЛ\КСВ использовать унсилирайзед файл, который даже и парсить не надо. Скрипт получит готовый массив для вывода.

Sams писал:

а зачем мне результат с ошибками ?

Ты тож немного не понял, результаты были бы без ошибки, просто если где то вдруг появиться лишний перевод строки, или ни дай бог из 2048 байтов в файле, сервер успел считать только 2047 - то стандартные ХМЛ парсеры выдают ошибку и 0 результатов.
КСВ выведет столько результатов - сколько успело нормально считаться. Можешь посмотреть на форумах как часто у людей результаты не показываются при использовании ХМЛ фидов, и немного подумать почему такое происходит.

В теории можно много рассуждать о том что проще\удобнее\быстрее, и конечно многие теоретические програмеры будут двумя руками за ХМЛ, но на практике, когда у вас будет реально большое кол-во трафика и большая нагрузка на сервер, то вы будете думать не о удобстве, а о скорости, надежности и ресурсоемкости. А хмл с этой точки зрения - отстой.