Сравнение производительности cryptoloop (losetup), dm-crypt (cryptsetup), dm-crypt LUKS (cryptsetup); AES vs blowfish

По правде говоря, сравнения AES vs Blowfish по сути нет. Blowfish был выбран исключительно для разнообразия эксперимента. Обычно в тестах подобного рода принято указывать кучу сопряженных параметров, я позволю себе практически все их опустить по одной простой причине — на качестве эксперимента они не отразятся, т.к. сравнение носит относительный характер, а не абсолютный. Отмечу лишь следущее:

  • для тестирования выбран обычный находившийся под рукой SATA диск — Seagate ST3250620NS. Процедуру инициализации устройств можно подсмотреть на странице ресурса OpenNet.RU;
  • в качестве базы выбрана файловая система ext2;
  • прямое влияние кэша файловой системы отсутствует, т.к. в обоих случаях: dd и bonnie++,- использовались файлы значительно большего размера, чем оперативная память;
  • вызов команды dd на запись dd if=/dev/zero of=<filename> bs=256k count=20000. Легко прикинуть, что результирующий файл составил 5000 MB. Флаг oflag=direct не использовался лишь по одной причине — на первых экспериментах я откровенно забыл его включить, а возвращаться к ним просто не хотелось;
  • вызов команды dd на чтение dd if=<filename> of=/dev/null bs=256k;
  • вызов команды bonnie++ -f -b -u 0

Результаты представлены на двух диаграммах. Полученные результаты представлены в формате CSV.





Итог достаточно радужный. Нетрудно заметить, что dm-crypt с LUKS EXTENSION продемонстрировала хорошие показатели, максимально приблизившись к показателям партиции без шифрования для случая записи и отстала от последней для случая чтения всего лишь на четверть (25%).

7 thoughts on “Сравнение производительности cryptoloop (losetup), dm-crypt (cryptsetup), dm-crypt LUKS (cryptsetup); AES vs blowfish

  1. Дельная статья, сам последнии пару недель ходил с подобной мыслью о тестировании, а тут как раз вы.

  2. А хранить на шифрованом програмным способом разделе файлы БД не пробовали? Интересно насколько критично по производительности будет.

    • Нет, задача заключалась в шифровании раздела для отдачи файлов большого раздела. ИМХО, шифрование может загубить на корню производительность БД.

      • На днях попробую все же потестить и отпишусь, очень критично для одной задачи хранить файлы postgres в шифрованом виде, ищу куда копать, может аппаратно шифровать hdd?

        • >> На днях попробую все же потестить и отпишусь,

          Было бы интересно посмотреть на результаты.

          >> может аппаратно шифровать hdd?

          В любом случае аппаратные решения дадут больший задел по производительности.

Добавить комментарий

Ваш e-mail не будет опубликован.