Оптимизация приложений в Access

Оптимизация аппаратных средств.

Каждый модуль Access обладает множеством возможностей для настройки приложения, но нельзя рассчитывать на какой-либо успех в работе, если компьютер, на котором выполняется приложение, является устаревшим или имеет недостаточно оперативной памяти. Microsoft в аннотации к Access указывает минимальные системные требования для компьютера. Но практика показывает, что подобных ресурсов хватает лишь на то, чтобы программа что называется «задышала», а вот чтобы нормально работать, требования надо серьезно увеличивать.

Если выбирать между модернизацией процессора и установкой ОЗУ большего объема, следует выб­рать ОЗУ. Как известно, памяти много не бывает, а Access, как и любая другая серьезная база данных, для своей нормальной работы требует значительного объема памяти.

Необходимо регулярно очищать корзину и удалять временные файлы (особенно файлы Internet и электронной почты!). Базы данных требует значительного объема дискового пространства, а эти файлы могут поглотить массу места еще до того, как пользователь успеет это осознать.

Не лишним будет регулярное сжатие базы данных. Начиная с версии Access 2000 это можно настроить автоматически. Сервис – Параметры – Вкладка общие – Сжимать при закрытии. Дело в том, что в Access есть своя «корзина», и при удалении записи не удаляются, а помечаются как удаленные (знаком *), то есть «становятся в очередь на удаление». Так же в Access есть скрытые системные таблицы, в которых хранятся параметры форм. Форму удалили, а параметры остались. Потом они конечно удалятся, но это потом. А пока мы имеем «мусор» - ненужные данные. По этой причине часто начинающие разработчики удивляются, когда после удаления (стирания) записей из базы ее размер почему то не очень изменяется. Особенно это касается полей типа OLE, где хранятся рисунки формата .bmp. Забили базу рисунками, она «раздулась» до нескольких десятков мБ, удалили рисунки – а размер остался. Выход – сжатие базы (дефрагментация). Так же замечено, что при регулярном сжатии база становиться более устойчивой - реже «слетает».

Рекомендуется отключить Journal (Журнал) в Outlook. Журнал Outlook генерирует запись при каждом запуске и выходе из приложения. Этот журнал может стать очень большим и поглощать дисковое пространство и процессорное время, необходимые приложению.

Необходимо использовать освободившуюся оперативную память. Приложения очень хорошо погло­щают оперативную память, но неохотно ее освобождают. Не стоит запускать несколько приложений одновременно. Вообще, желательно, чтобы машина, на которой установлена база, была ориентирована в первую очередь на работу с базой – не стоит ставить на нее ненужные программы. Особенно это касается машин, которые используются в качестве «серверов» при файл-серверном построении сетевой базы. А то иной раз частенько на таком «сервере» работают как на клиенте, да еще запускают какое-нибудь «навороченное» приложение, да и не одно, а потом удивляются, почему вдруг сетевая база стала «тормозить».

У многих разработчиков компьютеры намного более быстродействующие, чем у пользователей. Это следует учитывать при разработке приложения, и протестировать его на более «слабой» машине. Так же, если Вы разрабатываете приложение, не зная точно, какой Office будет у пользователя, будет не лишним протестировать его на всех версиях, на которых оно предположительно может быть установлено. Лучше всего установить на машине несколько операционных систем и на каждой соответствующую версию Office – это даст наиболее «чистый» результат тестирования. Так же если Вы переустанавливаете Office, то следует помнить, что многие «серьезные приложения» приложения «мусорят», если не сказать больше, в системный реестр. И чем «серьезнее» приложение, тем больше. Поэтому после удаления программы, не лишним будет прочистить реестр, например, при помощи RegCleaner, а то и вручную через RegEdit.exe, и «добить» что осталось через Norton Utilities Integrator.

Оценка производительности

Естественным является желание посмотреть, что же дала оптимизация, насколько быстрее стало работать приложение. API Windows предлагает таймер, который отслеживает время в миллисекундах. Функция timeGetTime() измеряет промежуток времени с момента запуска Windows. Поскольку она использует другой аппаратный счетчик, то возвращает время с точностью до миллисекунды. Используя timeGetTime(), можно вставить строку кода до и после выполнения любой критической опе­рации и получить очень точное измерение времени, которое понадобилось для завершения действия. Для использования вызова API необходимы две вещи: объявление функции и глобальная переменная для хранения времени запуска таймера. В разделе объявлений модуля необходимо ввести следующие три строки:

     Private Declare Function a2ku apigettime Lib "winmm.dll" Alias "timeGetTime" () As Long
     Dim Ingstartingtime As Long

Затем можно создать подпрограмму для запуска часов и функцию остановки часов.

     Sub a2kuStartClock()
          Ingstartingtime = a2ku_apigettime()
     End Sub

     Function a2kuEndClock()
          a2kuEndClock = a2ku_apigettime() - Ingstartingtime
     End Function

А вот пример использования этих функций:

' Определение времени выполнения запроса

     Sub QueryTimer(strQueryName As String)
     Dim db As Database
     Dim qry As QueryDef
     Dim rs as Recordset
          Set db = CurrentDb()
          Set qry = db.QueryDefs(strQueryName)
' Запуск часов. a2kuStartClock
          Set rs = qry.OpenRecordset()
' Остановка часов и вывод результата в окне отладки.
          Debug.Print strQueryName & " executed in:  " & a2kuEndClock & " milliseconds"
          rs.Close
     End Sub

Для достижения наибольшей точности измерения необходимо разместить вызов процедур a2kuStartClock и a2kuEndClock как можно ближе к местонахождению рассматриваемой процедуры.

Хотя определение времени играет не последнюю роль, но только на основе этой информации невоз­можно судить о производительности приложения во время разработки. Как уже говорилось выше, обычно у разработчика более высокоскоростной компьютер, стало быть тестирование не совсем «чистое», ведь таймер не может сообщить, как будет выполняться приложение на другом компьютере с меньшим объемом памяти или более низкоскоростным диском. Для более точного наблюдения за приложением можно воспользо­ваться другой недокументированной функцией — ISAMStats. Функция ISAMStats не документирована и не поддерживается, поэтому информацию, которую она сообщает, можно использовать лишь в качестве общих указаний. При запуске функция производит измерение шести важных оказывающих влияние на про­изводительность операций. Она подсчитывает все обращения чтения и записи на диск, обращения чтения в кэше, опережающего чтения, размещения блокировок и освобождения блокировок. Данную функцию можно использовать в Access 2000 и даже в более ранних версиях Access. Синтаксис функции очень простой:

     DBEngine.ISAMStats(опция,[reset])

     Существует шесть возможных значений для аргумента опция:

Необязательный параметр переустановки позволяет переустановить отдельные счетчики на нулевое значение. Чтобы воспользоваться данной функцией для оценки производительности, необходимо либо вычесть одни показания из предыдущих, либо переустановить счетчик на нулевое значение и затем вы-поднять оценку. Рассмотрим один из способов использования функции ISAMStats для оценки производительности.

     Sub PrintStats()
     Dim i As Integer
          Debug.Print
          Debug.Print "Disk Reads:  " & ISAMStats (0, Falsa)
          Debug.Print "Disk Writes:  " & ISAMStats(1, False)
          Debug.Print "Cache Reads:  " & ISAMStats(2, False)
          Debug.Print "Read-Ahead Cache Reads:  " & ISAMStats(3, False)
          Debug.Print "Locks Placed:  " & ISAMStats(4, False)
          Debug.Print "Locks Released: " & ISAMStats(5, False)
          For i = 0 To 6
               ISAMStats i, True
          Next
     End Sub

PrintStats может дать некоторое представление о том, почему одна методика работает быстрее, чем другая. Кроме того, эта информация может помочь сделать выбор между двумя подходами, выполнение которых занимает одинаковый промежуток времени. Взглянув на полученные данные, можно определить, как разная аппаратная конфигурация или больший набор данных может повлиять на производительность того или иного подхода. Рассмотренные функции полезны только при сравнении одной методики с другой. Бо­лее того, надежные результаты можно получить лишь в том случае, если усреднить данные многих тестов, проведенных при разных условиях. Данные две функции можно с легкостью объединить в одну для проведения подобных повторяющихся тестов.

Создание связей между таблицами в конструкторе (схема данных).

В предыдущих статьях уже говорилось о важности правильного задания связей между таблицами. Добавлю еще одно замечание: Jet (механизм баз данных - центр почти всего, что происходит в приложении баз данных Access) узнает о существовании соотношений в первую очередь из этого окна. Jet может использовать всю эту инфор­мацию для создания более эффективного плана оптимизации при запросах к данным. Это значительно повышает производительность.

Повышение скорости выполнения запросов.

Вот основные рекомендации:

Рекомендуется создавать индексы для всех полей, которые будут использованы для определения критерия отбора.

В результирующем наборе не следует отображать какие-либо лишние столбцы. Обработка и отобра­жение каждого столбца занимает дополнительное время.

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

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

По возможности следует пользоваться оператором Between для уменьшения количества строк в ре­зультирующем наборе вместо операторов "больше чем" и "меньше чем".

Рекомендуется по возможности поэкспериментировать с подчиненными запросами вместо исполь­зования объединений или сложных условий OR. Оптимальный выбор зависит от многих дискретных факторов, и только эксперимент поможет решить, какой подход использовать.

Вместо SQL-операторов в коде рекомендуется использовать сохраненные запросы с параметрами. Jet уже скомпилировал запросы с параметрами и создал для них план выполнения. Использование скомпилированных и сохраненных запросов устраняет необходимость оценки и оптимизации SQL-строки. Access компилирует SQL-строки, использующиеся в качестве источника записей или источника строк для форм, отчетов или элементов управления, поэтому они остаются нетронутыми. Поэтому рекомендуется всегда использовать скомпилированные (сохраненные) запросы.

Обсудить на форуме...

Автор: Admin Добавлен: 20.01.2007