Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

3.3. Серверы 181

запрос на дальнейшую обработку. После окончания обработки дочерний процесс

завершается.

Машина клиента

Машина сервера

Регистрация

конечной

точки

Таблица

конечных

точек

машина клиента 2. Продолжение Машина сервера

работы

со службой JJ Реальный

сервер

Запрос службы

Суперсервер

Создание

сервера

для запрашиваемой

службы

Рис. 3.6. Привязка клиента к серверу с использованием демона в среде DCE (а).

Привязка клиента к серверу с использованием суперсервера в UNIX (б)

Еще один момент, который следует принимать во внимание при создании сер-

вера,

—

когда и как сервер может быть прерван. Для примера рассмотрим поль-

зователя, который решил загрузить на FTP-сервер большой файл. Затем, начав

делать это, он обнаружил, что выбрал не тот файл и хотел бы отменить дальней-

шую пересылку данных. Существует несколько способов сделать это. Один из

подходов, кстати единственный, надежно работающий в современном Интернете

(а иногда и единственно возможный), — пользователь немедленно закрывает

клиентское приложение (что автоматически вызывает разрыв соединения с сер-

вером), тут же перезапускает его и продолжает работу. Сервер, естественно, раз-

рывает старое соединение, полагая, что клиент прервал работу.

Более правильный способ вызвать прерывание связи

—

разрабатывать клиент

и сервер так, чтобы они могли пересылать друг другу сигнал конца связи

{out-of-

band),

который должен обрабатываться сервером раньше всех прочих передавае-

мых клиентом данных. Одно из решений — потребовать от сервера просмат-

ривать отдельную управляющую конечную точку, на которую клиент будет от-

правлять сигнал конца связи и одновременно (с более низким приоритетом)

—

конечную точку, через которую передаются нормальные данные. Другой вари-

ант

—

пересылать сигнал конца связи через то же соединение, через которое кли-

ент пересылал свой запрос. В TCP, например, можно посылать срочные данные.

182 Глава 3. Процессы

Когда срочные данные достигают сервера, он прерывает свою работу (в UNIX-

системах

—

по сигналу), после чего может просмотреть эти данные и обрабо-

тать их.

И последний из важных моментов, о которых надо помнить при разработ-

ке,

—

должен или нет сервер хранить информацию о состоянии клиентов. Сервер

без фиксации

состояния {stateless

sewer) не сохраняет информацию о состоянии

своих клиентов и может менять свое собственное состояние, не информируя об

этом своих клиентов [55]. Web-сервер, например, это сервер без фиксации со-

стояния. Он просто отвечает на входящие HTTP-запросы, которые могут требо-

вать загрузки файла как на сервер, так и (гораздо чаще) с сервера. После выпол-

нения запроса web-сервер забывает о клиенте. Кроме того, набор файлов,

которыми управляет web-сервер (возможно, в комбинации с файловым серве-

ром),

может быть изменен без уведомления клиентов об этом действии.

В противоположность этому, сервер с фиксацией состояния (stateful server)

хранит и обрабатывает информацию о своих клиентах. Типичным примером

такого сервера является файловый сервер, позволяющий клиенту создавать ло-

кальные копии файлов, скажем, для повышения производительности операций

обновления. Подобный сервер поддерживает таблицу, содержащую записи пар

(клиент, файл). Такая таблица позволяет серверу отслеживать, какой клиент

с каким файлом работает и, таким образом, всегда определять самую «свежую»

версию файла. Подобный подход повышает производительность операций чте-

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

нию с серверами без фиксации состояния часто является основным преимущест-

вом и основной причиной разработки серверов с фиксацией состояния. Однако

данный пример также иллюстрирует основной недостаток таких серверов. В слу-

чае сбоя сервера он вынужден восстанавливать свою таблицу с записями пар

(клиент, файл), в противном случае не будет никакой гарантии в том, что работа

происходит с последней обновленной версией файла. Как правило, серверы с фик-

сацией состояния нуждаются в восстановлении своего состояния в том виде,

в котором оно было до сбоя. Как мы увидим в главе 7, необходимость обеспечить

восстановление после сбоя сильно усложняет программу. В случае архитектуры

без фиксации состояния вообще нет необходимости принимать какие-то специ-

альные меры по восстановлению серверов после сбоя. Они просто перезапуска-

ются и работают, ожидая запросов клиента.

При разработке сервера выбор между архитектурой с фиксацией и без фикса-

ции состояния не отражается на службе, которую этот сервер должен предостав-

лять.

Так, например, поскольку до выполнения чтения или записи файлы в лю-

бом случае должны открываться, сервер без фиксации состояния должен тем или

иным способом воспроизвести открытие файла. Стандартное решение, которое

мы более детально обсудим в главе 10, состоит в том, чтобы сервер, обрабатывая

запрос на запись в файл или чтение из файла, открывал нужный файл, выполнял

операцию чтения или записи и немедленно его закрывал.

В других случаях сервер может пожелать хранить записи о поведении клиен-

тов,

чтобы более эффективно обрабатывать их запросы. Так, например, web-сер-

веры иногда предоставляют клиентам возможность немедленно отправиться на

3.3. Серверы 183

любимые страницы. Это можно сделать только в том случае, если сервер будет

хранить информацию о клиенте. Традиционное решение состоит в том, чтобы

позволить клиенту отсылать дополнительную информацию о его предыдущих се-

ансах работы с сервером. Эта информация часто прозрачно сохраняется браузе-

ром клиента в виде файлов

cookie —

маленьких фрагментов данных, содержащих

информацию о клиенте, важную для сервера. Файлы cookie никогда не исполня-

ются браузером, они просто хранятся.

При первом обращении клиента к серверу последний пересылает файл cookie

вместе с запрошенными web-страницами браузеру, а браузер сохраняет этот файл

cookie. Каждый раз в дальнейшем при обращении клиента к серверу файлы

cookie пересылаются браузером на сервер вместе с текстом запроса. В теории этот

подход работает прекрасно, на деле же файлы cookie для безопасного хранения

отсылаются браузером назад на сервер часто совершению скрытно от пользователя.

Такая вот «великая» секретность. В отличие от бабушкиного печенья (cookie

—

печенье), эти cookie, как правило, следует оставлять там, где их «испекли».

3.3.2. Серверы объектов

После того как мы рассмотрели основные моменты, относящиеся к проектирова-

нию серверов, обсудим особый тип серверов, который становится все важнее.

Сервер объектов {object

sewer)

—

это сервер, ориентированный на поддержку рас-

пределенных объектов. Важная разница между стандартным сервером объектов

другими (более традиционными) серверами состоит в том, что сам по себе сер-

вер объектов не предоставляет конкретной службы. Конкретные службы реали-

зуются объектами, расположенными на сервере. Сервер предоставляет только

средства обращения к локальным объектам на основе запросов от удаленных

клиентов. Таким образом, можно относительно легко изменить набор служб, про-

сто добавляя или удаляя объекты.

Сервер объектов, соответственно, выступает как место для хранения объектов.

Объект состоит из двух частей: данных, отражающих его состояние, и кода, обра-

зующего реализацию его методов. Будут ли эти части храниться раздельно, а так-

же смогут ли методы совместно использоваться несколькими объектами, зави-

сит от сервера объектов. Кроме того, существует разница и в способе обращения

сервера объектов к его объектам. Например, в многопоточном сервере объектов

отдельный поток выполнения может быть назначен каждому объекту или каждо-

му запросу на обращение к объекту. Эту и другие тонкости мы сейчас и обсудим.

Альтернативы обращению к объектам

Для любого объекта, к которому происходит обращение, сервер объектов должен

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

поток выполнения для поддержки обращения и т. д. Простейший подход

—

счи-

тать,

что все объекты выглядят одинаково и обращение к ним может произво-

диться единообразно. Именно так работает среда DCE. К сожалению, подобному

подходу обычно не хватает гибкости, и он часто накладывает на разработчиков

распределенных объектов неоправданные ограничения.

184 Глава 3. Процессы

Более правильный подход со стороны сервера

—

поддерживать различные

правила обработки объектов. Рассмотрим, например, нерезидентные объекты.

Напомним, что нерезидентным называется объект, существующий только во вре-

мя существования сервера, а возможно, и еще более короткий срок. Типичной

реализацией нерезидентного объекта можно считать хранящуюся в памяти копию

файла, предназначенную только для чтения. Калькулятор (обычно запускаемый

на высокоскоростном сервере) также может быть реализован в виде нерезидент-

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

к нему, а уничтожить после того, как не останется связанных с этим объектом

клиентов. Преимущество подобного подхода состоит в том, что нерезидентные

объекты нуждаются в ресурсах сервера только до тех пор, пока в этих объектах

есть необходимость. Недостаток

—

в том, что обращение может потребовать для

выполнения определенного времени, поскольку объект еще нужно создать. По-

этому иногда применяется другая политика

—

все нерезидентные объекты созда-

ются при инициализации сервера. Это дается ценой выделения ресурсов на объ-

екты даже в том случае, если ни один клиент не станет их использовать.

Схожим образом сервер мог бы выделять каждому из своих объектов отдель-

ный сегмент памяти. Другими словами, можно запретить совместное использо-

вание объектами кода и данных. Подобный подход мог бы применяться в тех

случаях, когда для реализации каждого объекта не требуется отделять код от

данных или когда объекты нужно отделить друг от друга по соображениям без-

опасности. В этом последнем случае сервер должен будет для гарантированной

защиты границ сегментов предоставить специальные средства измерения или

требовать поддержки от базовой операцрюнной системы. При альтернативном под-

ходе можно позволить объектам совместно использовать хотя бы код. Так, база

данных, содержащая объекты, относящиеся к одному классу, может быть эффек-

тивно реализована путем однократной загрузки на сервер реализации этого клас-

са. В случае прихода запроса на обращение к объекту серверу достаточно будет

извлечь из базы данных состояние объекта и выполнить вызванный метод.

Подобным же образом существует множество разных подходов, относящихся

к работе с потоками выполнения. Простейший из них ~ реализация сервера

с единственным управляющим потоком выполнения. С другой стороны, сервер

может поддерживать несколько потоков выполнения

—

по одному на каждый

объект. В случае прихода запроса с обращеьпшм к объекту сервер просто передает

запрос потоку выполнения, отвечающему за этот объект. Если поток выполнения

в этот момент занят, запрос ставится в очередь. Преимущество такого подхода ~

в автоматической защите объектов от одновременного доступа: для единственно-

го связанного с объектом потока выполнения все обращения выстраиваются по

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

дому запросу, но при этом необходимо предварительно защитить объекты от од-

новременного доступа. Независимо от того, назначается поток выполнения каж-

дому объекту или каждому методу, нужно решить, создавать каждый поток по

запросу или поддерживать на сервере пул потоков. Оптимального решения «на

все случаи жизни» здесь быть не может.

3.3. Серверы 185

Адаптер объектов

Правила обращения к объекту обычно называют

политикой активизации

{activa-

tion

policies),

чтобы подчеркнуть тот факт, что во многих случаях объект, перед

тем как к нему можно будет обратргться, должен быть перемещен в адресное про-

странство сервера (то есть активизирован).

Нам нужен механизм группирования объектов в соответствии с политикой

активизации каждого из них. Этот механизм называют

адаптером объектов

(ob-

ject

adapter),

или

упаковщиком объектов (object

wrapper),

но чаще всего его суще-

ствование скрыто в наборе средств построения сервера объектов. Мы будем ис-

пользовать термин «адаптер объектов». Адаптер объектов прекрасно подходит

для программ, реализующих собственную политику активизации. Главное, одна-

ко,

что этот адаптер объектов является общедоступным для разработчиков рас-

пределенных объектов компонентом. Его нужно только сконфигурировать под

соответствующую политику.

Адаптер объектов контролирует один или несколько объектов. Поскольку

сервер должен одновременно поддерживать объекты с различной политикой ак-

тивизации, на одном сервере может одновременно работать несколько адаптеров

объектов. При получении сервером запроса с обращением к объекту этот запрос

сначала передается соответствующему адаптеру объектов, как показано на рис. 3.7.

Сервер с тремя объектами машина сервера

Заглушка объекта (скелетон)

Адаптер объектов Адаптер объектов

Демультипликатор

запросов

Локальная

операционная

система

Рис. 3.7. Организация сервера объектов

с разной политикой активизации

Важно отметить, что этот адаптер объектов не осведомлен о конкретных ин-

терфейсах объектов, которые он контролирует. Другими словами, он никогда не

бывает конкретен. Единственное, что для него важно,

—

возможность извлечь

186 Глава 3. Процессы

ссылку на объект из запроса и передать запрос объекту в соответствии с его по-

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

объекту адаптер передает запрос серверной заглушке этого объекта. Заглушка,

называемая еще скелетоном и обычно генеррфуемая из определения интерфейса

объекта, выполняет демаршалинг запроса (получает параметры запроса) и обра-

щается к соответствующему методу.

Для примера рассмотрим адаптер объектов, управляющий несколькими объ-

ектами. Адаптер реализует политику, в соответствии с которой каждым из объ-

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

скелетонами (у каждого объекта скелетон собственный), выполняющими мар-

шалинг и демаршалинг запросов, каждый скелетон должен реализовать следую-

щую операцию:

1nvoke(uns1gnecl in_size. char in_args[]. unsigned'^ out_s1ze. char* out_args[])

Здесь 1n_args

—

это массив байтов, который заглушка подвергает демарша

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

тода и значения для всех его параметров. Точный формат массива известен только

заглушке, которая и отвечает за действительный вызов. Параметр 1n_s1ze задает

размер массива in_args. Аналогичным образом заглушка выполняет маршалинг

всех выходных данных в массив out_args, который динамически создается за-

глушкой. Размер массива задается в выходном параметре out_s1ze (отметим, что

процедура Invoke соответствует версии для динамических вызовов, которая обсу-

ждалась в предыдущей главе).

В листинге 3.1 приведен заголовочный файл адаптера. Наиболее важная его

часть

—

определение сообщений, которыми обмениваются адаптер и удаленный

клиент.

Листинг

3.1.

Заголовочный файл адаптера header.h, используемый как адаптером, так и

всеми программами, которые к нему обращаются

1'^ Определения, необходимые адаптеру и тем программам, которые к нему обращаются */

#def1ne TRUE 1

#def1ne MAX_DATA 65536

/'^ Определение стандартного формата сообщения */

struct message {

long source; /* определение отправителя */

long object_1d; /"^ идентификатор запрашиваемого объекта */

long method_1d: /* идентификатор запрашиваемого метода '^1

unsigned size; /* число байтов в списке параметров */

char *data: /* параметры как последовательность байтов */

/* Общее определение операции, вызываемой для скелетона объекта '^1

typedef void (*METHOD_CALL) (unsigned, char*, unsigned*, char**):

long register_object(METHOD_CALL call); /* зарегистрировать объект */

void unregister_object(long objectjd); /* отменить регистрацию объекта */

void invoke_adapter(message *request) /* вызвать адаптер

3.3. Серверы 187

Каждый клиент производит маршалинг запроса в сообщение, содержащее

пять полей. Адаптер возвращает ответ в сообщении с аналогичной структурой.

Поле source определяет отправителя сообщения. Поля object^ld и method_1d опреде-

ляют соответственно объект и метод, к которым производится обращение. Ис-

ходные данные, передаваемые заглушке, помещаются в массив data, размер кото-

рого задается полем size. Результат обращения помещается в поле data нового

сообщения.

Заголовочный файл содержит также определение способа вызова адаптера

серверной заглушкой объекта путем определения типа

METHOD_CALL.

И наконец, адаптер предоставляет две процедуры, которые могут быть вызва-

ны сервером для регистрации и отмены регистрации объекта в адаптере. Регист-

рация производится путем передачи указателя на реализацию процедуры данно-

го объекта invoke (она реализована в заглушке объекта). Функция регистрации

возвращает число, которое может эффективно использоваться адаптером в каче-

стве идентификатора объекта. Для отмены регистрации сервер должен передать

это число путем вызова процедуры unreg1ster_object. Реальный вызов адаптера

происходит в ходе выполнения процедуры invoke_adapter, которая требует иден-

тификатор объекта и запроса. Результат этой операции, как показано ниже, бу-

дет помещен в отдельный буфер.

При реализации адаптера мы предполагаем, что доступный пакет потоков вы-

полнения предоставляет нам средства для создания (и уничтожения) потоков

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

полнения осуществляется посредством буферов. В частности, каждый поток

имеет собственный буфер, из которого он может удалять сообщения путем бло-

кирующей операции get^msg. Сообщения добавляются в буфер путем неблоки-

рующей операции put_msg. Основная часть заголовочного файла пакета потоков

выполнения представлена в листинге 3.2.

Листинг 3.2. Файл thread.h используется в адаптере для работы

с потоками выполнения

typedef struct thread THREAD: /* Скрытое определение потока */

THREAD *create_thread (void (*body)(Iong tid). long threadjd);

/* Создать поток путем передачи указателя на функцию, которая определяет текущее

поведение потока, вместе с целым, которое используется как уникальный идентификатор

потока */

void get_msg(unsigned *size. char **data):

void put_msg(THREAD ^receiver, unsigned size, char *data):

/* Вызов операции get_msg блокирует поток до тех пор. пока сообщение не попадет

в соответствующий буфер. Помещение сообщения в буфер потока - это неблокирующая

операция */

Мы подошли к реализации адаптера, приведенной в листинге 3.3. Каждый из

объектов имеет ассоциированный с ним поток выполнения, заданный процедурой

thread_per_object. Поток выполнения начинает работу с блокировки и остается

блокированным, пока запрос не окажется в буфере потока. Запрос немедленно

188 Глава 3. Процессы

передается заглушке объекта путем вызова 1nvol<e[object_1cl] с соответствующИхМ

значением параметра. Результат обращения к объекту возвращается в перемен-

ной results и копируется в ответное сообщение. Это ответное сообщение собира-

ется из полей object_1cl и method_id. За ними следует результат, который копиру-

ется в поле данных сообщения. В этом состоянии ответ пропускается через

демультиплексор, как показано на рис. 3.7. В нашем примере демультиплек-

сор реализуется отдельным потоком выполнения, идентифицируемом перемен-

ной root.

Листинг 3.3. Основная часть адаптера, реализующего политику

«один объект

—

один поток»

#1nclude <header.h>

#include <thread.h>

#def1ne MAX_OBJECTS

100

#def1ne NULL

#def1ne

ANY -1

/* Массив указателей

на

заглушки

METHOD_CALL invoke[MAX_OBJECTS]:

/* Поток выполнения демультипликатора

THREAD ^root;

По одному потоку выполнения на объект

THREAD nhread[MAX_OBJECTS];

void thread_per_object(long object_id)

(

message "^гец.

*res;

сообщения

запрос/ответ

unsigned size:

/'^

размер сообщений

char ^results;

массив со всеми результатами

while(TRUE)

{

get_msg(8tsize. (char*)

&req);

блокировка для запроса

Передача запроса соответствующей заглушке

Заглушка должна зарезервировать память для результатов

(invoke[object_id])(req->size. req->data. &size.

&results):

Создать ответное сообщение:

res

malloc(sizeof(message)+size):

Определить объект:

res->object_id

objectjd:

Определить метод:

res->method_id

req.method_id:

Установить размер результатов обращения:

res->size

size:

Скопировать результаты

ответное собщение:

memcpy(res->data. results,

size):

Добавить ответ

содержимому буфера:

put_msg(root.

sizeof(res).

res):

/•^ Освободить память, выделенную под запрос:

free(req):

Освободить память, выделенную под результаты:

free(results):

3.4. Перенос кода 189

}

void 1nvoke_adapter(long old. message ^request) {

put_msg(thread[oid]. sizeof (request), request);

}

Теперь реа7П1зация процедуры invoke^adapter несложна. Вызываемый поток

выполнения (в нашем примере

—

демультиплексор) добавляет свой запрос на

обращение к буферу потока, ассоциированному с объектом, к которому был за-

прошен доступ. Позднее демультиплексор может извлечь результаты из свое-

го собственного буфера и вернуть их клиенту, который и заказывал обращение

к объекту.

Важно отметить, что реализация адаптера не зависит от объектов, обращения

к которым он обрабатывает. Фактически в примере реализации нет никакого за-

висящего для объектов кода. Соответственно, можно создать обобщенный адап-

тер и поместить его на промежуточный уровень программного обеспечения. После

этого разработчикам серверов объектов можно сконцентрироваться исключи-

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

тер обращения к каким объектам должен контролировать.

Последнее замечание. Хотя на рис. 3.7 показан специальный компонент, кото-

рый занимается распределением поступивших запросов соответствующим адап-

терам (демультиплексор), он не обязателен. Для этой цели мы вполне могли бы

использовать адаптер объектов. Как мы увидим в главе 9, подобный подход реа-

лизован в технологии CORBA.

3.4. Перенос кода

До сих пор мы в основном обсуждали распределенные системы, в которых взаи-

модействие ограничивалось передачей данных. Однако существуют ситуации,

когда передача программ, иногда даже во время их выполнения, позволяет упро-

стить разработку распределенных систем. В этом разделе мы детально рассмот-

рим, как происходит перенос кода. Мы начнем с обсуждения различных подходов

к переносу кода и продолжим разговором о локальных ресурсах, которые исполь-

зуются переносимыми программами. Отдельной сложной проблемой является

перенос кода в гетерогенных системах. Об этом мы тоже поговорим. Чтобы вести

предметный разговор, в конце этого раздела мы рассмотрим систему D'Agents

для мобильных агентов. Отметим, что вопросы безопасности, связанные с пере-

носом кода, вынесены в главу 8.

3.4.1.

Подходы к переносу кода

Перед тем как рассматривать различные варианты переноса кода, обсудим спер-

ва, зачем подобный перенос может понадобиться.

190 Глава 3. Процессы

Причины для переноса кода

Традиционно перенос кода в распределенных системах происходит в форме пере-

носа процессов {process migration)у

в случае которых процесс целиком переносится

с одной машины на

другую.

Перенос работающего процесса на другую машину

—

дорогостоящая и сложная задача, и для ее выполнения должна быть веская при-

чина. Такой причиной всегда была производительность. Основная идея состоит в

том, что производительность может возрасти при переносе процессов с сильно

загруженной на слабо загруженную машину. Загрузка обычно выражается в по-

нятиях длины очереди к процессору

РШИ

загрузки процессора, используются так-

же и другие индикаторы производительности.

Алгоритм распределения загрузки, на базе которого принимаются решения,

включающие распределение и перераспределение задач в соответствии с имею-

щимся набором процессоров, играет важную роль в системах интенсивных вы-

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

вычислительной мощности

—

менее важная задача по сравнению, например, со

снижением коммуникационного трафика. Более того, учитывая гетерогенность

базовых платформ и компьютерных сетей, повышение производительности пу-

тем переноса кода нередко основывается скорее на качественных рассуждениях,

чем на математических моделях.

Рассмотрим, например, систему клиент-сервер, в которой сервер управляет

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

множество операций с базой данных, используя большие объемы данных, может

быть лучше перенести часть клиентского приложения на сервер, а по сети пере-

давать только результаты. В противном случае сеть может быть перегружена дан-

ными, передаваемыми с сервера на клиент. В этом случае перенос кода основан

на соображении о том, что обычно имеет смысл обрабатывать данные поблизо-

сти от того места, где они находятся.

Сходная причина может быть использована и при переносе части сервера на

клиент. Например, во многих интерактивных приложениях баз да1Н1ых клиент

должен заполнять форму, которая затем будет преобразована в серию операций

базы данных. Обработка формы на стороне клиента с пересылкой на сервер толь-

ко заполненной формы нередко позволяет избежать пересылки по сети значи-

тельного количества небольших сооби1ений. В результате клиент покажет луч-

шую производительность, а сервер затратит меньше времени на обработку формы

и взаимодействие.

Поддержка переноса кода может также помочь повысить производительность

на основе параллелизма, но без обычных сложностей, связанных с параллель-

ным программированием. Типичным примером может быть поиск информации

в Web. Относительно несложно реализовать поисковый запрос в виде неболь-

шой мобильной программы, переносимой с сайта на сайт. Создав несколько

копий этой программы и разослав их по разным сайтам, мы можем добиться ли-

нейного возрастания скорости поиска по сравнению с единственным экземпля-

ром программы.

Помимо повышения производительности существуют и другие причины под-

держания переноса кода. Наиболее важная из них

—

это гибкость. Традицион-