Агент заметок Lotus работает медленнее на сервере по сравнению с развитием ПК

Question

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

Вот проблема. Одним из требований было создание пустой записи для каждого персонала каждый день, для чего были внесены записи о посещаемости. Агент, который делает это, вызывает несколько процедур и выполняет некоторую проверку в базе данных. В настоящее время существует около 1800 пустых записей, созданных ежедневно. На ПК разработки обработка каждой записи занимает от 2 до 3 секунд, что соответствует среднему значению в полтора часа. Однако, когда мы развертывали его на сервере, обработка каждой записи занимает примерно 7 секунд, что примерно составляет 3 с половиной часа. У нас были случаи, когда агент занимает от 4,5 до 5 часов.

Обратите внимание, что в обоих случаях агенты запланированы. На сервере нет других приложений лотоса, и сервер является свободным и неактивным большую часть времени (ни одно другое приложение, кроме Windows Server и Lotus Notes). Есть ли что-то, что может привести к увеличению времени обработки по сравнению с ПК разработки и сервером?

Answer 1

Ваш процесс генерирует 1800 новых документов каждый день, и вы сказали, что вы также регулярно архивируете документы, поэтому я предполагаю, что это означает, что вы удаляете их после их архивирования. Проблемы производительности могут со временем нарастать в таких приложениях. Вероятно, в базе данных имеется большое количество удалений, и файл NSF, вероятно, сильно фрагментирован (внутренне и/или внешне).

Вы должны использовать бесплатную утилиту NotesPeek, чтобы изучить базу данных и посмотреть, сколько ее содержит заглушки удаления. Затем вы должны проверить purge interval setting и подумать о том, чтобы опустить его до наименьшего значения, которое вам удобно. (То есть, достаточно большой, чтобы вы знали, что все серверы и пользователи будут реплицироваться в течение этого времени, но достаточно малы, чтобы избежать возможности большого наращивания удаляемых заглушек.) Если вы измените интервал очистки, вы можете подождать 24 часа для того, чтобы заглушки были или вы можете вручную запустить updall против базы данных на консоли сервера, чтобы заставить ее.

Затем вы должны запустить compact -c в файле NSF, а также запустить дефрагментацию на томе на сервере, где находится NSF.

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

I.e., зайдите в свой код для архивирования и измените его, чтобы он не удалял их после архивирования. Вместо этого, ваш код маркирует их полем, таким как FreeDocList := "1". Затем добавьте скрытый вид под названием (FreeDocList) с формулой selction от FreeDocList = "1". Также зайдите в любое другое представление в базе данных и добавьте & (!(FreeDocList = "1")) в формулы выбора. Затем изменение кода добавляет новые пустые документы, поэтому вместо создания новых документов он просто переходит к представлению FreeDocList, находит первый документ, устанавливает FreeDocList = "0" и удаляет все предыдущие значения полей. Конечно, если документов FreeDocList недостаточно, ваш код вернется к старому поведению и создаст новый документ.

С вышеуказанными изменениями вы будете использовать все существующие документы, когда это возможно, вместо того, чтобы удалять и создавать новые. Я запускал тесты на код вроде этого и обнаружил, что он может помочь; но я не могу гарантировать это во всех случаях. Многое будет зависеть от того, что еще происходит в приложении.