Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Дополнительные инструменты в панели инструментов   
Шаблоны и примеры Читать статью
 
Классы для работы со стабами удалённых документов для Windows64   
Шаблоны и примеры Читать статью
 
Базовые компоненты XPages Extension Library: Widget Container   Серия статьей дающая представление о базовых компонентах Extension Library, их основных свойствах и мест применения
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Повышение производительности приложений Lotus Notes/Domino. Часть первая

Повышение производительности приложений Lotus Notes/Domino
Гусев А. В., Дмитриев А. Г.
Вычислительный центр ОАО «Кондопога» (г. Кондопога, Карелия)


В этой статье мы рассмотрим вопросы, касающиеся повышения производительности приложений для Lotus Notes\Domino. Для этого мы воспользуемся программным обеспечением (ПО) LNMark V1 (http://iskondopoga.snw.ru). В состав LNMark V1 входит 3 модуля:
  • Тестовая база данных (LNMarkV1.nsf);
  • Серверная компонента, запускаемая как стандартный сервис и предназначенная для считывания показателей загруженности процессоров сервера;
  • Программа тестирования LNMarkV1.exe, реализованная в среде Borland Delphi 6 SP3.

LNMark V1 содержит в себе 7 тестов – поиск документов в базе данных (БД), навигация по представления и поисковым коллекциям, чтение полей документа, запись полей документа, открытие отдельных документов в окне Lotus Notes и открытие всей БД.
Во время исследования тестовая база данных последовательно увеличивалась в объеме. Начальное состояние БД - 1344 документов (235 Мбайт), конечное состояние - 62192 документов (7264 Мбайт). Всего выполнено 8 исследований. Во время всех исследований каждый тест повторялся 100 раз, при этом определялось среднее время отклика сервера (вместе со среднеквадратическим отклонением), а также средняя загрузка всех процессоров сервера во время выполнения запросов. По результатам каждого теста построено 2 графика: зависимость времени отклика сервера от размера базы данных и зависимость загрузки процессора сервера от размера базы данных. Все тесты выполнены для 1 пользователя. После завершения выполнения всего исследования рабочая станция и сервер перегружались.
Характеристика сервера: Сервер (self-made), мат. Плата Asus HDL, 2 х Pentium 4 Xeon 2,8 GHz (Hyper Treading включен) / ОЗУ – 4 Гбайт / RAID 5 – 3 x Seagate SCSI-320 15000 rpm / гигабитный сетевой адаптер.
Характеристика рабочей станции: Spline Maestro Asus P4P800 / Pentium 4 3 GHz HT / RAM 1 Gb / HDD Seagate 80 Gb / гигабитный сетевой адаптер.

Рассмотрим подробно результаты выполнения каждого теста и проанализируем их влияние на общую производительность приложений Lotus Notes.

Тест 1. Поиск документов в базе данных стандартным методом Search




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

Тест 2. Навигация по коллекции документов, полученной методом Search и вычисление суммы объемов документов в коллекции

Этот тест использует полученную ранее методом Search коллекцию документов и осуществляет навигацию по этой коллекции. При этом вычисляется объем каждого документа (стандартное свойство Size объекта NotesDocument) и определяется общая сумма этих значений.



Как видно из графиков, навигация по коллекции документов фактически не зависит от объема базы данных. Также рост базы данных не приводит к повышению загрузки центрального процессора сервера при выполнении операций навигации по коллекции документов. Исходя из этого, а также учитывая результаты первого теста, можно сделать вывод: если в информационной системе имеется потребность обработать какую-то группу документов (коллекцию в терминах Lotus Notes), то следует получать ее из представлений в базе данных по какому-либо ключу (например, методом GetAllDocumentsByKey). При этом время обработки коллекции очень незначительно (в тесте – это в среднем 51,55 мс на коллекцию из 100 документов).

Кроме этого, по нашим наблюдениям, пошаговый перебор всех документов в коллекции, полученной методом GetAllDocumentsByKey, требует в среднем на 20-30% меньше времени, чем при обработке коллекции, полученной методом Search. Мы пока не смогли найти точного объяснения этому факту. Вероятнее всего, положительное влияние здесь оказывают функции кеширования на сервере – перебор коллекции из представления может использовать индекс самого представления, кешированный сервером – в отличие от перебора коллекции, полученной поиском. При этом следует учесть, что в ситуациях, когда из одного документа нужно получить значения нескольких полей (1-3), то вместо чтения значений полей в документах этого представления имеет смысл рассмотреть возможность навигации по entries (классы NotesViewEntryCollection и NotesViewEntry) – такой метод обеспечивает более быстрое выполнение перебора.

Еще одним преимуществом метода GetAllDocumentsByKey является то, что разработчик имеет возможность сортировать коллекцию документов стандартными средствами Lotus Notes. Наиболее простой способ – это использовать в представлении 2 сортированных столбца – первый столбец использует сортировку по ключевому полю, а второй – по дополнительному атрибуту. Коллекция NotesDocumentCollection, полученная методом Search, как следует из официальной документации, является несортированной. Однако это не совсем так – документы в этой коллекции распологаются в хронологическом порядке создания документов в этой базе данных. Это, вероятно, вызвано тем, что Lotus Notes просто перебирает всю базу данных при поиске методом Search и помещает в результирующую коллекцию найденные документы – которые, таким образом, образуют список, отсортированный по дате создания.

Например, в разрабатываемой нами медицинской информационной системе Кондопога (http://iskondopoga.snw.ru) очень часто возникает задача обработать документы по конкретному пользователю. Для эффективного решения этой задачи в каждом документе системы хранится UNID главного (родительского) документа пациента с описанием паспортной части (в поле ParUNID). Во всех базах данных предусмотрено скрытое представление, в котором отображаются все документы базы данных. В этом представлении имеется всего один, сортированный по полю ParUNID, столбец. Когда в системе возникает задача обработать некоторые документы пациента, то вначале система получает полную коллекцию всех документов пациента из этого представления методом GetAllDocumentsByKey, а затем «забирает» из него нужные документы. Время выполнения такой операции минимально и зависит только от того, сколько документов накоплено по данному пациенту, но не зависит от объема всей базы данных. Это позволяет гарантировать высокую производительность системы при росте базы данных.
Однако и в использовании навигационных методов имеются свои тонкости. Так, для больших баз данных (объемом свыше 2-3 Гбайт или количеством документов свыше 400 тыс.), хранящих документы с иерархической структурой, мы рекомендуем провести сравнительное исследование двух подходов.
  1. Согласно первому, коллекцию документов можно получить из представления, в котором все документы принятой иерархии отсортированы по некоему ключу. Когда нужно получить коллекцию, используется метод GetAllDocumentsByKey и полный перебор полученной коллекции.
  2. Согласно второму подходу, используется представление, в которое попадают только документы верхнего уровня в принятой иерархии, отсортированные по ключу. Для получения коллекции используется следующий алгоритм – вначале ищется документ верхнего уровня, используя метод GetDocumentByKey. Если такой документ найден, то используется стандартное свойство Responses класса NotesDocument для того, чтобы получить коллекцию всех документов-ответов найденного документа. И уже в этой коллекции полным перебором производится поиск тех документов, которые содержат нужное значение ключа – и их последующая обработка.

Возможно, последний алгоритм подходит далеко не для всех задач, однако его реализация может принести существенный выигрыш в производительности. Во-первых, использование метода GetDocumentByKey приводит к том, что Lotus Notes должен найти только первое совпадение в индексе представления и вернуть объект класса NotesDocument (метод GetDocumentByKey возвращает объект NotesDocumentCollection) – а это в ряде случаев может значительно экономить ресурсы сервера и снизить трафик по сети. Во-вторых, если в базе данных используется развитая иерархия документов, содержащая 3 и более вложений (документов типа Ответ на Ответ), то представление по второму подходу будет содержать гораздо меньше документов, а значит – меньший индекс и занимать меньше дискового пространства сервера. А это, в свою очередь, приведет к снижению накладных расходов сервера на обслуживание представления – особенно сильно это заметно в тех база данных, в которых документы часто добавляются, удаляются или изменяются. При этом, по нашим замерам, полный перебор коллекции документов, полученной через свойство Responses, будет выгоднее по времени, чем ожидание исполнения метода GetAllDocumentsByKey.



Тест 3. Изменение поля в коллекции и запись измененного документа в БД (BackEnd методами)


Результаты этого теста наглядно демонстрируют, что изменение полей в документе и запись этих изменений фактически не зависит от объема базы данных – линейный вид графиков и подобранные формулы являются неоспоримым доказательством.
Следует помнить, что использование метода ReplaceItemValue класса NotesDocument осуществляется фактически моментально. А вот запись этих изменений методом Save класса NotesDocument требует гораздо больше ресурсов сервера. Это связано, во-первых, с необходимостью передать изменения на сервер по сети. Во-вторых, после записи изменений сервер должен обновить представления в базе данных в соответствии с заданными формулами отбора документов и дизайном столбцов. И чем больше представлений, настроенных на автоматическое обновление, используется в базе данных, тем больше нагрузка на сервер. И, кроме этого, если какие-то представления были обновлены, сообщение об этих изменениях должны быть переданы на все рабочие места, использующие текущую базу данных.
Таким образом, повышение производительности работы приложений Lotus Notes при записи изменений может быть достигнуто лишь за счет сокращения вызовов метода Save класса NotesDocument. Мы рекомендуем тщательно проверять программы на предмет использования метода Save - рекомендуется применять его только один раз, после внесения всех исправлений в поля документа – обычно в конце программы. Если изменение полей осуществляется только по ряду условий, то рекомендуется использовать следующую принципиальную схему:
Неоптимальный алгоритм
Наиболее быстрый алгоритм
Dim Doc as NotesDocument
Set Doc = …

If <Условие 1> then
   Call Doc.ReplaceItemValue(<Field1>, <NewValue1>)
   Call Doc.Save(True,False)
End If

If <Условие 2> then
   Call Doc.ReplaceItemValue(<Field2>, <NewValue2>)
   Call Doc.Save(True,False)
End If

If <Условие 3> then
   Call Doc.ReplaceItemValue(<Field3>, <NewValue3>)
   Call Doc.Save(True,False)
End If
Dim Doc as NotesDocument
Dim IsDocNeedToSave as Boolean
Set Doc = …
IsDocNeedToSave=False ‘ Пока документ сохранять не надо

If <Условие 1> then
   Call Doc.ReplaceItemValue(<Field1>, <NewValue1>)
   IsDocNeedToSave=True
End If

If <Условие 2> then
   Call Doc.ReplaceItemValue(<Field2>, <NewValue2>)
   IsDocNeedToSave=True
End If

If <Условие 3> then
   Call Doc.ReplaceItemValue(<Field3>, <NewValue3>)
   IsDocNeedToSave=True
End If

‘ Запись изменений осуществляется, только если
‘ это необходимо
If IsDocNeedToSave Then  Call Doc.Save(True,False)

Тест 4. Открытие документа из коллекции в окне Lotus Notes для чтения (FrontEnd методами)




Как видно из графика, время открытия документа в окне Lotus Notes линейно зависит от объема базы данных. Отметим, что мы использовали достаточно сложную структуру документа и наполнение, содержащее много текста, графику и таблицы, различное шрифтовое оформление и т. д. Поэтому начальное значение на открытие в 2 сек. при объеме БД примерно 500 Мбайт и конечное значение в 20 сек. при объеме БД 7 Гбайт являются вполне ожидаемыми. Более щадящий подход к проектированию структуры документа, а также использование небольших документов по объему, безусловно, приведут к значительному сокращению этого показателя и, возможно, к наклону графика зависимости времени открытия документы от объема БД к горизонтальной оси.

Сам показатель времени открытия документа зависит от очень многих факторов:
  • Количество полей – чем их меньше, тем быстрее открывается документ
  • Наличие полей, вычисляемых при открытии, приводит к увеличению времени открытия документа. Особенно сильно затормаживают поля, в которых используются поисковые и навигационные формулы, например – DBLookUP
  • Наличие графических элементов в оформлении документа
  • Использование обработчиков событий QueryOpen и QueryModeChange документа и т.д.
Продолжение >>>

Смотрите также русскоязычные материалы на сайте IBM:
Производительность сервера Lotus Domino 7. Часть 1. Рабочие нагрузки от клиентов Lotus Notes >>>
Производительность сервера Lotus Domino 7. Часть 2. Производительность Domino 7 для пользователей Domino Web Access >>>
Производительность сервера Lotus Domino 7. Часть 3. Производительность корпоративной почты >>>
 
  Опубликовано — 11/17/2005 |    



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :

Мероприятия
18.12.2012   Опыт реализованных проектов на базе технологий IBM
24.10.2012   Решения IBM для построения надежной ИТ-инфраструктуры и сервисов
09.10.2012   Форум «Ударим СЭДом по бездорожью, разгильдяйству и непрозрачным бизнес-процессам! Система электронного документооборота CompanyMedia 4.0: вперед в будущее!»
Пресс-релизы
02.06.2011   ООО "АДБ.РУ" выпустило очередную версию системы управления контентом для Lotus Domino - Logosphere 2.7.
21.01.2010   Компания «Поликом Про» выполнила для компании «Синергия» пилотный проект по внедрению системы защиты электронной почты IBM Lotus Protector for Mail Security
22.12.2009   Новые технологии разработки приложений на базе Lotus Domino
Биржа труда
18.04.2012 - разработчик Lotus Notes (ОАО "УРАЛСИБ")
26.07.2011 - Программист Lotus (удаленная работа) ()
06.06.2011 - Эксперт (Lotus Notes/Domino) (Крупный банк (ТОП-5))
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU