Это не задача Ignite. Пусть этим занимаются специализированные системы. Тогда задача Ignite упрощается до сбора метрик и их передачи в эти самые специализированные системы.
Все верно. В текущей реализации метрики с частотой heartbeat'а собираются по discovery со всего кольца, что на большом количестве кэшей приводит к пересылке и боработке десятков мегабайтов данных не имеющих прямого отношения к хранению и обработке пользовательских данных. Переход к хранению только локальных метрик и отказ от агрегации избавляет систему от этого недостака.
Методика тестирования действительно имеет ряд минусов:
То, что в зачет идет операция по уничтожению кэша действительно плохо. Во-первых, это никак не относится к тестируемым операциям. Во-вторых, уничтожение кэша само по себе не очень быстрое.
Сравнение локального кэша на cache2k с рапсределенным Ignite конечно же плохая идея. Да, в выводах об этом сказано, но хотелось бы лишний раз это подчеркнуть.
Использование FULL_ASYNC в рапределенном кэше привносит дополнительный оверхед при записи в кэш. Значение по умолчанию обычно PRIMARY_SYNC.
Бенчмарк для cache2k не копирует ключи и значения из кэша при чтении, в конфигурации Ignite про эту особенность забыли. Свойство кэша copyOnRead по умолчанию имеет значение true. Для более корректного сравнения нужно конечно же изменить его на false.
Как вы правильно заметили, умение готовить Ignite может кардинально изменить значения бенчмарков. Хотя, скорее всего, полученные значения будут несколько хуже чем у cache2k, в силу его заточенности под локальный кэш.
он хранится в не абы в чём, не в java.util.concurrent.ConcurrentHashMap, как кто-то, наверное подумал, а в org.jsr166.ConcurrentHashMap8. В чём их отличие даже боюсь предположить, надеюсь, что кто-нибудь в комментах просветит.
Ignite написан на Java 7, тогда как класс ConcurrentHashMap в Java 8 получил ряд улучшений. Вот его и перенесли из jsr166 в кодовую базу Ignite и немного модифицировали. Благо лицензия CC0 это позволяет.
Стоило написать статью, как релизнулась версия 3.2.1.
Счетчик на базе AtomicInteger будет работать корректно только в случае одного экземпляра вашего чата. Как только вы запустите несколько вертиклов чата, начнете получать некорректные значения.
Неубедительно. Ничто не мешает мне повысить уровень абстракции путем написания нужного кода и сокрытия его за красивыми методами. Плюс есть ряд библиотек, которые уже позволяют это сделать. Java 8 опять же облегчит труд нашим пальцам.
Ничего не имею против Scala. Просто неубедительно.
Ваш цикл на Java будет всегда выполнять ровно итерацию. Это делает статью еще менее убедительной, а оптимизацию по sqrt(N) вместе с комментарием и вовсе бессмысленными.
1) Сама идея билдера такова, что ошибка программиста может привести к неправильной инициализации конструируемого класса.
2) Много методов билдера + необходимость создавать иерархию билдеров — мне уже видится ошибкой. Судить не зная контекста трудно.
В общем для малой глубины иерархии, я бы все-таки использовал композицию.
Если иерархия будет расти, то согласен, параметризация классов уменьшает кол-во работы и кол-во возможных ошибок при добавлении потомка. Но сама идея вызывает недоверие.
Да, понадобится делегирование вызовов к вложенному инстансу. Но в этом решении есть жирный плюс — оно простое, и, как следствие, легко поддерживаемое.
Прозрачность для пользователя здесь роли не играет. Так или иначе его не волнует, как это устроено внутри (по крайней мере не должно). Он видит интерфейс и работает с ним.
А вообще, иерархия классов с иерархией билдеров не выглялит как хорошая идея.
Дать посмотреть DVD — это добросовестное использование контента. Законом такие действия не преследуются. Такое же право у меня должно быть и по отношению к фильму, купленному в ином формате.
Забавно, весело. Только нужно заранее быть психологически готовым к тому, что один из участников диалога не в курсе этих рекомендаций. Как в ПДД, которые гарантируют результат только при условии их соблюдения всеми участниками.
А вообще, стоит наверное почаще закидывать такие «социалочки» :)
Подписку требует на прослушивание радио на основе рекомендаци1. Предлагается отслушать в тестовом периоде 30 композиций, а потом нужно платить 3$ в месяц. Как раз подумываю о том, чтобы подписаться и в полном объеме заценить работу этого сервиса.
Что касается интернет-радиостанций, то это опять же другая песня. Я не спец, но по-моему, интернет-радиостанции на западе работают по принципу обычных радиовещательных сетей. Там денежная составляющая по другому устроена.
Так или иначе, ситуация пока все еще не в пользу традиционных рекламных моделей в интернете. Но для правообладателей это вполне себе выход: они провайдеры контента, а сервисы — рекламные площадки, которые могут делиться. Осталось в этой схеме еще подвинуть поставщиков рекламы таким образом, чтобы они больше денег отдавали партнерам, тогда все может заработать.
Ценители качественного звука — не целевая аудитория таких сервисов. С точки зрения бизнеса сервис должен удовлетворять массы, а не «маргинальных элементов». Возможно что-либо подобное когда-нибудь появится, но стоить будет заметно дороже.
MTV — в смысле телеканал? Иам совсем другая история, которая привела к тому, что музыки на канале практически нет.
last.fm ввел подписку скорее всего как раз для того, чтобы привлечь дополнительные средства на лицензионные отчисления. И не думаю, что у них договоренности с крупными лейблами. Кстати подписка — это уже не рекламная модель.
Ну а про тысячи вы лукавите :)
Речь не идет о вставке рекламы в сами звуковые файлы. Речь идет о модели, при которой сервис делится рекламными доходами (например от Директа или AdSense) с правообладателями.
Скажем так, они плохо адаптируются. Правообладатели очень неохотно идут на монетизацию своего контента по рекламной модели. Они видят, что доход, получаемый по такой модели существенно ниже, чем продажи физического носителя или файлов в интернет магазинах. Единственное, на что с радостью идут правообладатели — это продажа контента сервисам с их лицензированием, а это очень большие деньги, которые сервисам сложно потом вернуть (вспомним Yota-музыку).
Кстати и интернет-магазины не могут просто взять и начать торговать музыкой. Они также вынуждены покупать этот контент, что делает порог входа в этот бизнес очень высоким в долларовом выражении. На мой взгляд правообладателям было бы в данном случае выгоднее идти с ресейлерами на сотрудничеству по принципу сдачи «товара» на реализацию.
Что касается халявщиков, то их не так уж и много, и потери от них крайне малы. Большая часть так называемых халявщиков — это люди, которые не имеют удобного способа получения и оплаты контента, а потому идущие по пути наименьшего сопротивления, т.е. по пути халявы.
Как вы правильно заметили, умение готовить Ignite может кардинально изменить значения бенчмарков. Хотя, скорее всего, полученные значения будут несколько хуже чем у cache2k, в силу его заточенности под локальный кэш.
Ignite написан на Java 7, тогда как класс ConcurrentHashMap в Java 8 получил ряд улучшений. Вот его и перенесли из jsr166 в кодовую базу Ignite и немного модифицировали. Благо лицензия CC0 это позволяет.
Счетчик на базе AtomicInteger будет работать корректно только в случае одного экземпляра вашего чата. Как только вы запустите несколько вертиклов чата, начнете получать некорректные значения.
Ничего не имею против Scala. Просто неубедительно.
Ваш цикл на Java будет всегда выполнять ровно итерацию. Это делает статью еще менее убедительной, а оптимизацию по sqrt(N) вместе с комментарием и вовсе бессмысленными.
1) Сама идея билдера такова, что ошибка программиста может привести к неправильной инициализации конструируемого класса.
2) Много методов билдера + необходимость создавать иерархию билдеров — мне уже видится ошибкой. Судить не зная контекста трудно.
В общем для малой глубины иерархии, я бы все-таки использовал композицию.
Если иерархия будет расти, то согласен, параметризация классов уменьшает кол-во работы и кол-во возможных ошибок при добавлении потомка. Но сама идея вызывает недоверие.
Прозрачность для пользователя здесь роли не играет. Так или иначе его не волнует, как это устроено внутри (по крайней мере не должно). Он видит интерфейс и работает с ним.
А вообще, иерархия классов с иерархией билдеров не выглялит как хорошая идея.
А вообще, стоит наверное почаще закидывать такие «социалочки» :)
Я просто говорю о том, что правообладатели считают недостаточным вознаграждение от показа рекламы на сайте.
А обзор вышеупомянутых сервисов сделать не помешает. Заодно примете участие в культивации платных сервисов в рунете ;)
Что касается интернет-радиостанций, то это опять же другая песня. Я не спец, но по-моему, интернет-радиостанции на западе работают по принципу обычных радиовещательных сетей. Там денежная составляющая по другому устроена.
Так или иначе, ситуация пока все еще не в пользу традиционных рекламных моделей в интернете. Но для правообладателей это вполне себе выход: они провайдеры контента, а сервисы — рекламные площадки, которые могут делиться. Осталось в этой схеме еще подвинуть поставщиков рекламы таким образом, чтобы они больше денег отдавали партнерам, тогда все может заработать.
last.fm ввел подписку скорее всего как раз для того, чтобы привлечь дополнительные средства на лицензионные отчисления. И не думаю, что у них договоренности с крупными лейблами. Кстати подписка — это уже не рекламная модель.
Ну а про тысячи вы лукавите :)
Речь не идет о вставке рекламы в сами звуковые файлы. Речь идет о модели, при которой сервис делится рекламными доходами (например от Директа или AdSense) с правообладателями.
Кстати и интернет-магазины не могут просто взять и начать торговать музыкой. Они также вынуждены покупать этот контент, что делает порог входа в этот бизнес очень высоким в долларовом выражении. На мой взгляд правообладателям было бы в данном случае выгоднее идти с ресейлерами на сотрудничеству по принципу сдачи «товара» на реализацию.
Что касается халявщиков, то их не так уж и много, и потери от них крайне малы. Большая часть так называемых халявщиков — это люди, которые не имеют удобного способа получения и оплаты контента, а потому идущие по пути наименьшего сопротивления, т.е. по пути халявы.