Агент Lotus Notes работает на сервере медленнее, чем на ПК для разработки

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

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

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


person alteredego86    schedule 05.04.2013    source источник
comment
Вам нужно включить отладку, чтобы получить время для ваших методов в вашем приложении, и сузить его до связанного кода. После этого опубликуйте образец.   -  person Simon O'Doherty    schedule 05.04.2013
comment
Что именно вы подразумеваете под «на ПК для разработки»? Означает ли это, что у вас есть локальная реплика и вы запускаете агент, выбирая его в меню? Или вы используете реплику сервера, но по-прежнему выбираете агента из меню? И, развернув его на сервере, вы имеете в виду, что он работает как запланированный агент?   -  person Richard Schwartz    schedule 05.04.2013
comment
Используйте профайлер: lotus-blogs.blogspot.sk /2007/08/   -  person Frantisek Kossuth    schedule 05.04.2013
comment
@SimonO'Doherty Я поставлю операторы печати с отметками времени для каждого метода.   -  person alteredego86    schedule 08.04.2013
comment
@RichardSchwartz Да, у нас есть локальная реплика, для которой вносятся и тестируются изменения перед внедрением на сервер с использованием шаблонов и заменяющих дизайнов. Кроме того, мы запускали агент по расписанию на локальной реплике, чтобы эмулировать среду развертывания на сервере.   -  person alteredego86    schedule 08.04.2013
comment
@FrantisekKossuth Я также попробую ваш метод для профилирования агента. Спасибо.   -  person alteredego86    schedule 08.04.2013


Ответы (1)


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

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

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

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

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

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

person Richard Schwartz    schedule 08.04.2013