Клиент-сервер

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

ватель Нэнси, имеющая IP-адрес 150.121.1.102, сообщила об ухудше­нии производительности приложения ввода заказов, основанного на пуле соединений (архитектура приложения приведена на рис. 6.3). Приложение никак не способствует выделению данных расширенной трассировки SQL для Нэнси.

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

Более эффективный обходной маневр - временное изменение архитек­туры, которое бы изолировало сеанс Нэнси. Один из способов реализа­ции такого изменения изображен на рис. 6.4, где изоляция сеанса Нэнси обеспечена за счет предоставления ей собственного процесса на сервере приложений и отдельного выделенного серверного процесса Oracle. Для того чтобы реализовать такой переход, можно, например, назначить Нэнси специальный «идентификатор службы» (аналог спе­циального псевдонима TNS для уровня служб приложения), который

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

Противники этого метода обычно отмечают, что изменение архитекту­ры может оказать влияние на производительность исследуемого сеан­са Нэнси. Однако эти изменения имеют более локальный характер, чем в первом случае, т. к. мы не изменяем нагрузку, конкурирующую с действиями Нэнси. Конечно же, необходимо будет изучить сделан­ные изменения, особенно если окажется, что перемены в архитектуре повлияли на производительность. Например, если измененная архитектура, представленная на рис. 6.4, демонстрирует значительно бо­лее высокую производительность, чем архитектура на рис. 6.3, то сле­дует задуматься, не является ли виновником низкой производитель­ности процесс сервера приложений httpdO.

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

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

7 Принципы работы архитектуры клиент-сервер

По сети циркулируют только SQL-запросы/ответы (а не фрагменты или отдельные записи СУБД, как в архитектуре файл-сервер), благодаря чему резко снижается нагрузка на сеть. Обработка данных при этом более равномерно распределяется между клиентом и сервером.