> Большинство приставок из тех, что мне известны, действительно реализованы на Linux
Поясните, плз, что вы подразумеваете под «приставками»? AppleTV и аналоги? Тогда я совсем перестаю что-либо понимать, получается что огромное количество пользователей (10% — SmartTV, плюс часть из тех, кого вы посчитали в «компьютеры на линукс») предпочли смотреть на телевизоре не телевизионный сигнал, ни кабельное, а интернет-трансляцию. Это крайне странно, на мой взгляд.
>По доле ОС: в чём-то вы правы, но не до конца. В случае с Олимпиадой был активный пиар различных приложений для устройств, поэтому мы впервые сталкиваемся с такими цифрами.
Приложений для каких устройств? Айфонов-андридов? Да. SmartTV? Может быть. Линуксы и «приставки» на линуксе? Крайне сомнительно.
> Но от себя могу добавить, что каждая трансляция отличается от предыдущей
Опять же, смотря какая трансляция. Понятно, что трансляцию конференции по линуксу будут смотреть много линуксоидов. Но, таки, если это спортивное событие, то выборка смотрящих должна быть репрезантативной для всего множества смотрящих спорт в онлайне.
> И буквально с каждым разом всё больше смотрят с телефонов/планшетов.
Это тоже вполне очевидно. Я о трансляциях, прошедших в относительно небольшом временном интервале.
Вот, кстати, у Вас же наверняка есть логи какой-нибудь популярной трансляции, которая с помощью вашего продукта вещалась. Может Вы подтвердите/опровергните такую долю линукса? Мне кажется, что при большом количестве запросов, доля ОС для любой трансляции примерно одинаковой должны быть (кроме, разве что, телевизоров, для которых играет наличие приложения).
если CDN-сервер стоит в Лондоне, а клиент и origin в Питере, то выгоды, действительно, немного. Вообще толку от CDN, который стоит далеко от клиента (речь о http-статике, для видео всё несколько иначе) нет, один вред. А вот представьте, что сайт в Питере, клиент в Екатеринбурге, и CDN-edge тоже в Екатеринбурге. Схема меняется с Екатеринбург -> Питер на Екатеринбург -> Екатеринбург (CDN) -> Питер (origin). Но во второй схеме есть один нюанс — между CDN-сервером и origin tcp-соединение уже установлено и tcp-окно уже раздуто (я про slow start). Поэтому клиент экономит на tcp-handshake минимум RTT между Питером и Екатеринбургом и tcp-окно расширяется между ним и сервером CDN несколько бестрее из-за малого RTT. Т.е. выгода есть даже без сжатия на длинном учатске (CDN-origin == Екатеринбург-Питер). Если на длинном участке трафик будет ещё и эфективно сжиматься, то всё станет ещё чуть лучше.
ну хадуп это же фреймворк для выполнения mapreduce задач, который берёт на себя решения ряда проблем, возникающих при кластерных вычислениях, таких как доставка данных до процесса, выполнение задач (по возможнсти) близко к данным, сортировка промежуточных результатов, перезапус задачи при неудаче etc. Ваш bash-скрипт на 10 строчек тоже это будет уметь?
Вы, видимо, не совсем правильно понимаете посыл моего первого комментария. Тот факт, что инструменты надо выбирать под стать задаче не вызывают сомнений, но иллюстрации, на мой взгляд совершенно дикие. Mapreduce не имеет смысла на одной машине, xargs же на кластере порождает проблем больше чем решает. Как их вообще можно сравнивать? Копать червей эксаватором никому в голову не приходит, так же как и прокладывать канализацию гастарбайтерами с лопатами. Вы же говорите что лопаты лучше потому что к ним не нужен специально обученный экскаваторищик. Путаница тёплого с мягким.
> Конечно, понадобится Hadoop MapReduce
> Буэ, к чертям эту ерунду:
> find crawl_dir/ -type f -print0 | xargs -n1 -0 -P32 ./process
Экскаватор? Буэ, к чертям эту ерунду: десяток гастарбайтеров с лопатами! На самом деле, я доверяю лопате больше чем самому себе!
rfc1918?
Если клиент может достучаться до резолвера по серой сети, то это наверняка означает, что они географически близко и для определения ближайшего сервера авторитетному днсу вполне достаточно адреса резолвера. Описанная схема актуально для резолверов, обслуживающих географически распределённых клиентов.
Ещё раз задача:
У вас есть сервер в европе и сервер в америке. Вы хотите чтобы статическая страничка www.example.com/index.html отдавалась для европейских пользователей с европейского сервера, а для американских — с американского. Причём по одному урлу и без редиректов.
Вы настраивайте свой DNS так чтобы на запросы с европейских ip www.example.com резолвился в адрес европейского сервера, а с американских — в адрес американского.
А теперь к вам приходит запрос от гуглоднса. Какой адрес ему отдать?
А чем принципиально задача уменьшения минимизации rtt отличается от задачи минимизации географического расстояния? Это просто метрики, все алгоритмы одинаковые. Для минимизации rtt _тоже_ нужно знать адрес клиента, а не его днса.
Для таргетирования рекламы такие фокусы не нужны.
Авторитетному серверу передавать первые три октета адреса клиента. Сейчас если вы пользуетесь днсом гугла, то авторитетный днс не знает ничего о вашем фактическом местоположении — к нему пришёл запрос от гуглоднса. В предлагаемой схеме запрос состоит не просто из адреса, а из пары (адрес, первые три октета клиентского адреса), таким образом авторизованный сервер может выдать ответ учитывая ваше фактическое местоположение. Кэширование тоже будет производиться по двум параметрам.
Ну так документировать надо. Зная основные идеи, изложенные в локальной вики, например, знакомый с линуксцами человек разберётся достаточно быстро, имхо. На хардварных маршрутизаторах будь то циско или что угодно ещё, иногда тоже весьма навороченные конфиги в которых не так просто разобраться.
ну, в линуксце есть NAPI. Насколько мне известно, на фре нет ничего подобного, там либо поллинг либо прерывания. Хотя интеловкие карты генерируют прерывания по похожему алгоритму и, возможно, тюнингом параметров генерации прерываний можно добиться существенного уменьшения количества прерываний. Но на фре мы особо не тестировались. Да, и 9.6гбит это на 10ге интеловкой карточке, на гигабитных результаты поскромнее. Хотя, там проблемы были, скорее, в эзерченеле, на 1 сетевухе прокачивается ~990мбит.
Поясните, плз, что вы подразумеваете под «приставками»? AppleTV и аналоги? Тогда я совсем перестаю что-либо понимать, получается что огромное количество пользователей (10% — SmartTV, плюс часть из тех, кого вы посчитали в «компьютеры на линукс») предпочли смотреть на телевизоре не телевизионный сигнал, ни кабельное, а интернет-трансляцию. Это крайне странно, на мой взгляд.
>По доле ОС: в чём-то вы правы, но не до конца. В случае с Олимпиадой был активный пиар различных приложений для устройств, поэтому мы впервые сталкиваемся с такими цифрами.
Приложений для каких устройств? Айфонов-андридов? Да. SmartTV? Может быть. Линуксы и «приставки» на линуксе? Крайне сомнительно.
> Но от себя могу добавить, что каждая трансляция отличается от предыдущей
Опять же, смотря какая трансляция. Понятно, что трансляцию конференции по линуксу будут смотреть много линуксоидов. Но, таки, если это спортивное событие, то выборка смотрящих должна быть репрезантативной для всего множества смотрящих спорт в онлайне.
> И буквально с каждым разом всё больше смотрят с телефонов/планшетов.
Это тоже вполне очевидно. Я о трансляциях, прошедших в относительно небольшом временном интервале.
я очень сомневаюсь, что это будет хотя-бы удалённо напомитать хадуповский мапредьюс.
> Буэ, к чертям эту ерунду:
> find crawl_dir/ -type f -print0 | xargs -n1 -0 -P32 ./process
Экскаватор? Буэ, к чертям эту ерунду: десяток гастарбайтеров с лопатами! На самом деле, я доверяю лопате больше чем самому себе!
Если клиент может достучаться до резолвера по серой сети, то это наверняка означает, что они географически близко и для определения ближайшего сервера авторитетному днсу вполне достаточно адреса резолвера. Описанная схема актуально для резолверов, обслуживающих географически распределённых клиентов.
Ещё раз задача:
У вас есть сервер в европе и сервер в америке. Вы хотите чтобы статическая страничка www.example.com/index.html отдавалась для европейских пользователей с европейского сервера, а для американских — с американского. Причём по одному урлу и без редиректов.
Вы настраивайте свой DNS так чтобы на запросы с европейских ip www.example.com резолвился в адрес европейского сервера, а с американских — в адрес американского.
А теперь к вам приходит запрос от гуглоднса. Какой адрес ему отдать?
Для таргетирования рекламы такие фокусы не нужны.
Linux sh6 2.6.32-5-686-bigmem #1 SMP Sat Jul 24 03:13:16 UTC 2010 i686 GNU/Linux