Введение

Пользователи MyTetra задают мне один и тот же вопрос: насколько много данных можно хранить в MyTetra, и как быстро она будет работать с базой большого размера? Меня тоже интересует этот вопрос, и я давно уже сделал прикидочные расчеты, но расчеты — расчетами, а для объективности все-таки нужны практические замеры.

Для того, чтобы сделать замеры производительности, вначале нужно определиться, какой объем данных считать "большим". Учитывая, что MyTetra — это менеджер накопления персональной информации (PIM-менеджер), то имеет смысл ориентироваться на сведения о размерах баз, хранимых в подобных программах. У меня таких сведений только две штуки:

• Личные сведения: за время активного использования MyTetra c 2008 по текущий 2017 год, у меня скопилось 5000 заметок. То есть, это статистика за 9 лет. Средний прирост — 555 записей в год.
• Сведения от автор сервиса Evernote Степана Пачикова. В одном из своих интервью году в 2010 он обмолвился о 20000 записей. Учитывая, что он делал записи в прототипе, созданном в 2002 году, это количество записей он сделал за ~8 лет. Средний прирост — 2500 записей в год.

Здесь нужно сделать ремарку, и сказать о том, что концепции у MyTetra и Evernote разные. MyTetra — это медленная и скрупулезная работа с записями. Evernote — это создание быстрых заметок обо всем, включая фотографии текущих цен в магазинах. Поэтому скорость прироста массива записей Evernote брать для расчета не имеет смысла. Возьмем среднее арифметическое, примерно 1500 записей в год. То есть, это некий абстрактный человек, который собирает в MyTetra данные в три раза быстрее меня.

Прогноз сделаем на 50 лет. Делать прогноз на 100 лет считаю занятием неблагодарным. С учетом скорости в 1500 записей в год, база абстрактного сверхбыстрого человека будет содержать 75000 записей. Округлим это число вверх до значения 100000.

Таким образом, нагрузочное тестирование будет сделано на 100 000 записей.

Тестирование

Для создания тестовой базы был написан PHP-скрипт (см. файл /script/generateBase.php в ветке experimental). Параметры генерируемой базы следующие:

• Уровень вложения веток: 3
• Количество веток на одном уровне вложения: 19
• Количество записей в одной ветке: 15

При такой структуре дерева записей, тестовое дерево содержит чуть больше 100 000 записей. Параметры одной заметки следующие:

• Длина заголовка записи: 25 - 100 символов
• Длина текстовых меток (суммарно): 10 - 100 символов
• Длина заметки: 2000 - 4000 символов

Параметры одной заметки ни на что практически не влияют, и есть только одна вещь, которая связана с размером текста заметки — это полный поиск по всем текстам записей.

В результате работы скрипта была создана база MyTetra на 108 584 записей. Количество веток 7238. Размер каталога с базой получился 1.35Гб. Размер файла дерева mytetra.xml 40.5Мб.

Открыть в полном размере

Тестирование проводилось на достаточно старом для 2017 года железе:

• Микропроцессор: Intel Core2 Duo CPU E8400 @ 3.00ГГц
• Память: 4Гб, DDR2, 800 МГц
• HDD: 640 Гб, Western Digital WDC WD6400AAKS-00A7B0, SATA 2
• Материнка: ASUSTeK P5QL/EPU
• Ядро ОС: 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux
• Файловая система: ext4, преобразованная из исторической ext3

Замеры делались вручную с помощью секундомера. Замеры делались 5 раз, значения округлялись до арифметического среднего. Для коротких временных интервалов (менее 10 сек) погрешность может быть большой, потому что нужно было одновременно щелкать мышкой и кнопкой секундомера. Результаты следующие:

• Запуск программы: без задержек
• Раскрытие веток и отрисовка списка записей в ветке: без задержек
• Открытие текста записи: без задержек
• Редактирование текста записи и переключение на другую запись: без задержек
• Создание новой записи: 2.38 сек.
• Редактирование атрибутов записи: 2.35 сек.
• Поиск записи с использованием только метаинформации (название, текстовые метки): 6.17 сек.
• Полнотекстовый поиск записи по всей базе: 1 мин. 11 сек.

Термин "без задержек" обозначает, что визуальные задержки, способные уловиться глазом, отсутствуют.

Трактовка результатов

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

Ожидаемо, те действия, которые приводят к измененям в дереве записей (создание новой записи, редактирование атрибутов записи), зависят от скорости перегенерации XML-дерева, которое при каждом таком изменении перегенерируется и пересохраняется на диск. Генерация XML-дерева размером более чем 100 000 узлов и запись его на диск за 2.38 сек. на древнем железе — это хороший показатель. Бороться с этой задержкой можно путем создания подсистемы параллельной отложенной записи на диск. Вопрос в том, является ли время 2.38 сек. в некоторых действиях достаточным поводом для того, чтобы затеивать такую переделку.

Текстовый поиск записи с использованием только метаинформации за 6.17 сек. может вызвать некоторый дискомфорт, сравнимый со скоростью поисковой выдачи в сети Интернет через ADSL модем. Учитывая, что в настоящий момент поиск происходит линейно, и никаких методов индексирования не применялось, здесь есть пространство для оптимизации.

Полнотекстовый поиск записи по всей базе с точки зрения конечного пользователя достаточно медленный. Причины те же, что и у поиска по метаинформации. Но здесь есть некоторая загадка: объем данных для полнотекстового поиска в примерно в 60 раз больше, чем объем данных для поиска по метаинформации. Однако время, затрачиваемое на полнотекстовый поиск, больше всего в 10 раз. Это говорит о том, что поиск по метаинформации недостаточно оптимизирован. Возможно, тут влияет сильная дефрагментация участков памяти DOM-объектов, в которых хранится метаинформация.

Учитывая, что использование полнотекстового поиска дело достаточно редкое, и, кроме того, существует возможность сужать область поиска отдельной веткой, то острота данной проблемы значительно снижена.

Выводы

В том виде, в котором существует программа сейчас, программа поддерживает работу с базой в 100 000 заметок. Самыми времяёмкими действиями являются действия поиска по всей базе. Это ожидаемо, и решается только внедрением механизмов индексации записей.

Учитывая, что объем базы в 100 000 записей реально можно накопить через ~50 лет, и что в тесте использовалось старое железо, а, например, использование SSD-винчестеров уже дает ускорение чтения/записи минимум в 10-20 раз, то можно сделать вывод о том, что работа MyTetra v.1.42 на железе 2067 года будет достаточно комфортна, даже с учетом потенциального замедления закона Мура.

Конечно, никто не собирается запускать MyTetra v.1.42 в 2067 году. У меня есть некоторая надежда на то, что к этому году MyTetra будет иметь более свежую версию. Поэтому, в заключение, можно сказать: оставайтесь с нами и следите за новостями. Впереди у нас большая работа.