Как стать автором
Обновить

Комментарии 4

Методика тестирования действительно имеет ряд минусов:

  1. То, что в зачет идет операция по уничтожению кэша действительно плохо. Во-первых, это никак не относится к тестируемым операциям. Во-вторых, уничтожение кэша само по себе не очень быстрое.
  2. Сравнение локального кэша на cache2k с рапсределенным Ignite конечно же плохая идея. Да, в выводах об этом сказано, но хотелось бы лишний раз это подчеркнуть.
  3. Использование FULL_ASYNC в рапределенном кэше привносит дополнительный оверхед при записи в кэш. Значение по умолчанию обычно PRIMARY_SYNC.
  4. Бенчмарк для cache2k не копирует ключи и значения из кэша при чтении, в конфигурации Ignite про эту особенность забыли. Свойство кэша copyOnRead по умолчанию имеет значение true. Для более корректного сравнения нужно конечно же изменить его на false.


Как вы правильно заметили, умение готовить Ignite может кардинально изменить значения бенчмарков. Хотя, скорее всего, полученные значения будут несколько хуже чем у cache2k, в силу его заточенности под локальный кэш.
Согласен с критикой. Единственное, что я не уверен, действительно ли идёт в зачёт поднятие узла и удаление кэша. Надо посмотреть, как там устроено в JMH, может сервисные операции выносятся за скобки.
Сравнение, мягко говоря, не очень корректное. ConcurrentHashMap тупо хранит ссылки на объекты в памяти, а Ignite — это распределённый кэш, там затраты на сериализацию, передачу по сети (если ключ на другой ноде) и многое другое.

Ignite нужен, когда данные не влезают в память одной машины.

Сравнивайте IMDG с IMDG, например с Hazelcast 3.6 (или 3.7).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории