# К вопросу производительности DataparkSearch
DataparkSearch - Полнофункциональная поисковая машина для Интернета и Интранета с открытым исходным кодом. Распространяется по лицензии GNU.
Keywords: shareware, freeware, интернет, unix, поисковик, поисковая машина, поиск, поиск информации, интранет, open source, opensource, search, searching, software, udmsearch, engine, indexing, system, web, ftp, http, cgi, php, SQL, MySQL, database, php3, FreeBSD, Linux, Unix, DataparkSearch, MacOS X, Mac OS X, Windows, 2000, NT, 95, 98, GNU, GPL, url, grabbing

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