DataparkSearch Engine 4.53: Справочное руководство
Пред. | Глава 5. Хранение данных | След.

# 5.3. К вопросу производительности DataparkSearch

Способ хранения cache - самый быстрый в DataparkSearch. Используйте его, если хотите получить максимальную скорость поиска.

Если после окончания индексирования содержимое вашей директории `/var` не изменяется, вы можете выключить блокировку файлов при открытиии используя команду "ColdVar yes" в файле `search.htm` (или в файле `searchd.conf`, если используется searchd). Это позволит вам сэкономить некоторое время, затрачиваемое на блокировку файлов.

## 5.3.1. Рекомендация использовать searchd

Если вы планируете использовать синонимы, стоп-слова или данные ispell, рекомендуется воспользоваться демоном searchd (См. Разд. 5.4>). Демон searchd при запуске загружает эти данные и держит их в памяти. Это позволяет сократить среднее время выполнения запросов на поиск.

Таже searchd может загружать предварительно в память некоторые данные об URL (по 20 байт на каждую проиндекированую страницу) и лимиты cache mode (4 или 8 байт на каждый URL в зависимости от типа лимита). Это позволяет сократить среднее время обработки запроса.

## 5.3.2. Рекомендация использовать файловую систему в памяти (mfs)

Если вы планируете использовать cache mode и имеете достаточно оперативной памяти на вашем компьютере, вы можете разместить директорию `/usr/local/dpsearch/var` на файловой системе в памяти компьютера (mfs). Это ускорит как индексирование, так и поиск.

Если памяти недостаточно, что поместить в ней `/usr/local/dpsearch/var` целиком, вы можете разместить на mfs любую из директорий `/usr/local/dpsearch/var/tree`, `/usr/local/dpsearch/var/url` или `/usr/local/dpsearch/var/store`.

## 5.3.3. Команда URLInfoSQL

Для способа хранения cache вы можете использовать команду URLInfoSQL no для выключения сохранения информации об URL в SQL-базе. Однако использовав эту команду, вы потеряете возможность использовать лимиты по языку и типу документов.

## 5.3.4. Команда MarkForIndex

По умолчанию, DataparkSearch помечает все URL, отбираемые к индексированию, как ожидающие индексирования через 4 часа. Это позволяет избежать возможного одновременного индексирования одно и того же URL двумя параллельно запущеными копиями indexer. Однако для больших поисковых баз эта операция пометки может занять некоторое время. Вы можете выключить такую пометку используя команду "MarkForIndex no" в вашем файле конфигурации `indexer.conf`.

## 5.3.5. Команда CheckInsertSQL

По умолчанию, DataparkSearch пытается добавлять данные в SQL-базу вне зависимости, есть она уже там или нет. На некоторых системах, это может вызывать к дополнительной обработке сообщений об ошибках. Чтобы избежать таких ошибок, Вы можете добавить команду CheckInsertSQL yes в ваш файл конфигурации `indexer.conf`.

## 5.3.6. Производительность MySQL

Пользователи MySQL могут задать опцию `DELAY_KEY_WRITE=1` для таблиц DataparkSearch. Это позволит быстрее обновлять индексы, т.к.они не будут записываться на диск пока файл не будет закрыт. `DELAY_KEY_WRITE` целиком исключает обновление индексов на диске.

С этой опцией индексы хранятся только в памяти и записываются на диск в последнюю очередь, по команду FLUSH TABLES или по завершению mysqld. Запись одновлённых индексов на диск может занимать минуты и нетерпеливые пользователи могут прибить сервер командой `kill -9` и этим разрушить индексные файлы. Другим неудобством является необходимость запуска `myisamchk` для этих таблиц перед стартом mysqld для проверки, на случай, если `mysqld` был убит до этого.

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

## 5.3.7. Оптимизация после индексирования

Этот раздел был добавлен Randy Winch `<gumby@cafes.net>`

У меня есть мысля о производителности, которая может заинтересовать некоторых из вас. Я использую `RH 6.2` с обновлением ядра `2.2.14-6.1.1` (поддерживает файлы свыше 2 гигабайт) и `mysql 2.23.18-alpha`. Я проиндексировал весь наш сайт используя mnoGoSearch 3.0.18:

              mnoGoSearch statistics

        Status    Expired      Total
       -----------------------------
           200     821178    2052579 OK
           301        797      29891 Moved Permanently
           302          3          3 Moved Temporarily
           304          0          7 Not Modified
           400          0         99 Bad Request
           403          0          7 Forbidden
           404      30690     100115 Not found
           500          0          1 Internal Server Error
           503          0          1 Service Unavailable
       -----------------------------
         Total     852668    2182703

Я оптимизировал данные, выгрузив их в файл используя `SELECT * INTO OUTFILE`, отсортировал их при помощи системной процедуры сортировки по полю `word (CRC)` и затем загрузил их обратно в базу данных, используя процедуру, описанную в mysql online manual.

Производительность великолепна. Мой любимый тест - поиск "John Smith". Оптимизированная база показала результат в 13 секунд. База до оптимизации показывала примерно 73 секунды.

    Search results: john : 620241 smith : 177096
    Displaying documents 1-20 of total 128656 found

## 5.3.8. Библиотека асинхронного резолвера

Использование c-ares, библиотеки асинхронного резолвера (dns/c-ares в коллекции портов FreeBSD), позволяет для каждой индексирующей нити выполнять запросы к DNS без блокировки. Пожалуйста учтите, это также повышает число одновременных запросов к вашему DNS серверу.

Пред. | Начало | След.
Способ хранения Cache | Уровень выше | Поддержка SearchD