Главная | Обратная связь | Поможем написать вашу работу!
 МегаЛекции

Оптимизация клиентского приложения




Методы оптимизации клиентского приложения мало чем отличаются от методов оптимизации обычных приложений C++Builder. Обычно оптимизация заключается в повышении быстродействия приложения и в снижении объема используемых ресурсов операционной системы.

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

Избегать лишних связей с сервером следует не только из-за лишней перегрузки сети и сервера, но и из-за того, что они поглощают некоторое количество ресурсов и замедляют работу приложения.

Еще одним способом экономии ресурсов клиентского приложения является использование более экономичных интерфейсных элементов в случаях, где это возможно (например, TDBText или TLabel вместо TDBEdit, TLabel вместо TDBMemo при отображении полей, редактирование которых не предполагается, TDBGrid вместо TDBControlGrid и т.д.).

Еще один прием, повышающий быстродействие клиентского приложения, заключается в сокращении числа операций, связанных с выводом данных из таблиц на экран, например, при "пролистывании" большого количества строк в компонентах типа TDBGrid или TDBCtrlGrid в процессе навигации по набору данных или какой-либо их обработки. В этом случае рекомендуется на время отключать связь интерфейсных элементов с компонентом TDataSource, установив значение его свойства Enabled равным false (пример использования этого приема будет приведен ниже).

О навигационных методах и "клипперном" стиле програмирования

Говоря об оптимизации клиент-серверных информационных систем, хотелось бы отдельно остановиться на одной очень распространенной ошибке, совершаемой программистами, имеющими большой опыт работы с настольными СУБД и средствами разработки, базирующимися на xBase-языках, такими, как Clipper, dBase, FoxPro и др. При использовании средств разработки такого рода какое-либо изменение данных в таблице согласно каким-либо правилам осуществляется обычно путем создания цикла типа:

USE HOLDINGS

GO TOP

DO WHILE!EOF()

PUR_PRICE=PUR_PRICE+10

SKIP

ENDDO

CLOSE

В приведенном фрагменте xBase-кода PUR_PRICE - имя поля таблицы HOLDINGS, подверженного изменению.

При переходе к архитектуре клиент/сервер и средствам разработки, поддерживающим SQL, поначалу возникает естественное желание продолжать писать подобный код, используя циклы и навигацию по таблице. Это не так страшно в случае использования C++Builder с настольными СУБД - локальный SQL, способный быть альтернативой в этом случае, в конечном итоге также инициирует перебор записей таблицы. Вообще говоря, то же самое происходит и при выполнении запроса типа UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10 на сервере баз данных, но подобный цикл является внутренним процессом сервера, в котором не задействованы ни клиент, ни сеть. Однако при использовании "клипперного" стиля программирования библиотека BDE вовсе не обязана догадываться, что имел в виду программист, написавший подобный цикл, и генерирует вовсе не такие запросы!

Рассмотрим простой пример. Создадим копию таблицы HOLDINGS.DBF из входящей в комплект поставки C++Builder базы данных DBDEMOS на каком-либо сервере баз данных, например, Personal Oracle (воспользовавшись, например, утилитой Data Migration Wizard из комплекта поставки Borland C++Builder). Затем создадим новое приложение, состоящее из одной формы, включающей компоненты TDBGrid, TTable, TDataSource, TQuery, TDBNavigator и три кнопки (рис.3).

Установим следующие значения свойств используемых компонентов (табл.1):

Таблица 1.

Компонент Свойство Значение
DBNavigator1 DataSource DataSource1
DBGrid DataSource DataSource1
Button1 Caption 'Use SQL'
Button2: Caption 'Update records'
Button3: Caption 'Exit'
DataSource1 DataSet Table1

Table1

 DatabaseName ORACLE7
TableName HOLDINGS
UpdateMode UpWhereKeyOnly
Table1PUR_PRICE FieldName 'PUR_PRICE'

Query1

 DatabaseName ORACLE7
SQL 'UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10'

Теперь создадим обработчики событий, связанные с нажатием на кнопки. Кнопка Update records реализует аналог фрагмента xBase-кода, приведенного выше:

void __fastcall TForm1::Button2Click(TObject *Sender)

{

Table1->First();

DataSource1->Enabled=false; //Не будем издеваться над видеоадаптером!

while (!Table1->Eof)

{

Table1->Edit();

Table1PUR_PRICE->Value=Table1PUR_PRICE->Value+10;

Table1->Next();

}

DataSource1->Enabled=true; //Посмотрим, что получилось...

}

Временное отключение связи между DataSource1 и Table1 в данном обработчике событий сделано для того, чтобы исключить перерисовку компонента DBGrid1 при изменении каждой записи.

Кнопка Use SQL реализует выполнение одиночного SQL-запроса UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10:

void __fastcall TForm1::Button1Click(TObject *Sender)

{

Query1->Prepare();

Query1->ExecSQL();

Table1->Refresh(); //Посмотрим на результат...

}

Скомпилировав приложение, запустим SQL Monitor и посмотрим, какие запросы генерируются BDE при нажатии на эти кнопки.

При использовании кнопки Update records log-файл имеет следующий вид:

14:37:08 SQL Prepare: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

14:37:08 SQL Execute: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

14:37:08 SQL Stmt: ORACLE - Close

14:37:08 SQL Prepare: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:08 SQL Execute: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:08 SQL Misc: ORACLE - Set rowset size

14:37:08 SQL Stmt: ORACLE - Fetch

14:37:08 SQL Stmt: ORACLE - EOF

14:37:08 SQL Stmt: ORACLE - Close

14:37:08 SQL Prepare: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

И так далее, пока не кончатся все записи:

14:37:10 SQL Prepare: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:10 SQL Execute: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:10 SQL Misc: ORACLE - Set rowset size

14:37:10 SQL Stmt: ORACLE - Fetch

14:37:10 SQL Stmt: ORACLE - EOF

14:37:10 SQL Stmt: ORACLE - Close

Отметим, что это еще не самый большой набор запросов для данного случая, так как при обновлении таблицы было использовано значение UpWhereKeyOnly свойства UpdateMode компонента Table1, при котором запросы на обновление одной записи имеют минимальный набор проверяемых параметров.

При использовании кнопки Use SQL log-файл имеет совершенно другой вид:

14:35:51 SQL Prepare: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:35:51 SQL Transact: ORACLE - Set autocommit on/off

14:35:51 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10 14:35:51 SQL Stmt: ORACLE - Close

Остальные SQL-запросы, содержащиеся в log-файле, генерируются BDE при выполнении метода Refresh() компонента Table1:

14:35:51 SQL Prepare: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:35:51 SQL Execute: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:35:51 SQL Misc: ORACLE - Set rowset size

14:35:51 SQL Stmt: ORACLE - Fetch

14:35:51 SQL Stmt: ORACLE - EOF

14:35:51 SQL Stmt: ORACLE - Close

14:35:51 SQL Prepare: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE (("ACCT_NBR" IS NULL OR "ACCT_NBR">:1)) ORDER BY "ACCT_NBR" ASC

14:35:51 SQL Execute: ORACLE - SELECT "ACCT_NBR","SYMBOL","SHARES","PUR_PRICE","PUR_DATE","ROWID" FROM "HOLDINGS" WHERE (("ACCT_NBR" IS NULL OR "ACCT_NBR">:1)) ORDER BY "ACCT_NBR" ASC

14:35:51 SQL Misc: ORACLE - Set rowset size

14:35:51 SQL Stmt: ORACLE - Fetch

Если из текста обработчика события Button1Click удалить строку

Table1->Refresh();,

то действия с 5-го по 14-е выполняться не будут. Кроме того, при нажатии на эту же кнопку несколько раз подряд log-файл будет иметь следующий вид:

14:11:36 SQL Prepare: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:11:36 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:11:40 SQL Stmt: ORACLE - Reset

14:11:40 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:14:17 SQL Stmt: ORACLE - Reset

14:14:17 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:14:19 SQL Stmt: ORACLE - Reset

Как видим, компиляция запроса сервером осуществляется в этом случае только один раз.

Итак, мы видим, что "клипперный" стиль программирования при работе с SQL-серверами абсолютно неприемлем - он приводит к перегрузкам сервера, сети и рабочей станции одновременно, а разница в скорости выполнения заметна даже при небольшом объеме таблицы и использовании локального сервера, поэтому, анализируя причины низкой производительности приложений, стоит посмотреть - а нет ли в клиентском приложении подобных фрагментов кода?

В заключение хотелось бы отметить, что оптимизация клиент-серверных информационных систем должна производиться с учетом результатов анализа производительности и тщательного тестирования, возможно, не только с помощью SQL Monitor, но и с помощью специальных средств тестирования, обладающих дополнительными функциональными возможностями.

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://www.realcoding.net/
Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...