Статьи

Почему мой кластер в памяти работает хуже: отрицательное влияние на сеть

Доступ к памяти намного быстрее, чем дисковый ввод-вывод, поэтому многие из нас ожидают получить поразительные преимущества в производительности, просто развернув распределенный кластер в памяти и начав читать данные с него. Однако иногда мы упускаем из виду тот факт, что сеть связывает узлы кластера с нашими приложениями, и это может быстро уменьшить положительный эффект наличия кластера в памяти, если много данных передается непрерывно по проводам.

При этом использование надлежащих шаблонов доступа к данным, обеспечиваемых технологиями распределенной памяти, может свести на нет эффект задержки в сети. В этой статье мы используем API-интерфейсы вычислительной платформы Apache Ignite в памяти, чтобы увидеть, как изменяется производительность нашего приложения, если мы оказываем меньшее давление на каналы связи. Конечная цель заключается в том, чтобы иметь возможность развертывать горизонтально масштабируемые кластеры в памяти, которые могут подключаться к пулу оперативной памяти и процессорам, распределенным по всем машинам, с минимальным влиянием сети. 

Проведение простого эксперимента

Для простоты предположим, что в нашем кластере Apache Ignite в памяти хранятся тысячи записей, и приложению необходимо рассчитать самую высокую температуру и самое длинное расстояние в наборе данных. Необходимо сравнить три API-интерфейса, чтобы показать, как изменяется производительность при минимальном использовании сети: отдельные вызовы значения ключа, массовые чтения значения ключа и совместные вычисления. 

Для этого эксперимента подходит местный ноутбук. Таким образом, я развернул на своем компьютере двухузловой кластер Ignite и запустил этот пример с более чем 200 000 записей, предварительно загруженных на узлы (MacBook Pro начала 2015 года с двухъядерным процессором Intel Core i5 с тактовой частотой 2,7 ГГц и DDR3 с частотой 867 ГБ 1867 МГц и 8 ГБ). Эти два узла кластера и приложение взаимодействовали через петлевой сетевой интерфейс и конкурировали за ресурсы ОЗУ и ЦП. Если мы проведем тот же тест в действительно распределенной среде, то разница между сравниваемыми API будет более заметной. Я рекомендую вам поэкспериментировать с другими конфигурациями развертывания, следуя инструкциям, приведенным в примере. 


Вам также может понравиться:
Oracle In-Memory на практике .

Подчеркивая сеть с тысячами вызовов по значению

Мы начинаем с API-интерфейсов ключ-значение, которые извлекают каждую запись по одной из двух узлов. Ignite предоставляет стандартный   cache.get(key)  метод API для этого (проверьте calcByPullingDataFromClusterна полную реализацию):


Джава