Как повысить производительность приложения клиент-серверной архитектуры?

Question

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

• Клиент - Java Swing
• Сервер - RMI
• База данных Java - Oracle

Клиенты находятся в разных частях мира, но сервер Java и база данных Oracle находятся на одной машине в Швеции. Из-за этого существует большая задержка в сети. Клиенты, расположенные в отдаленных местах, имеют ужасную производительность. Приложение используется для обработки файлов размером более 50 МБ. Каждая операция в целом требует более 1000 сетевых вызовов.

Исходя из вашего опыта, как вы решаете эту проблему и повышаете производительность?

РЕДАКТИРОВАТЬ: Чтобы ответить на несколько вопросов

1. Файлы содержат фактические бизнес-данные, которые необходимо обработать и обновить в базе данных, которые не могут быть отправлены частично.
2. Некоторые сетевые вызовы могут быть пакетными, но это потребует серьезного рефакторинга кода. Это очень старое приложение, написанное еще в 2001 году. И дизайн приложения таков, что сервер содержит все сервисы, и они сделаны повторно используемыми в коде, а бизнес-логика написана на стороне клиента. Итак, эта бизнес-логика многократно вызывает сервер и, следовательно, астрономическую цифру.

-Snehal

Answer 1

Уменьшите количество поездок в оба конца

1000 рейсов за одну операцию - астрономическая фигура. Вы не должны видеть эти цифры.

У вас все еще есть проблема с файлами размером 50 МБ. В этом случае вам нужно будет либо найти способ сделать передачу более эффективной (передавать только дельты между двумя одинаковыми файлами?), Либо использовать какое-то кэширование.

WAN-трафик убивает ваше приложение, и, похоже, у вас есть серьезный рефакторинг.

Answer 2

Отправка больших файлов и большого количества запросов по сети стоит много времени. Период. Даже если вы могли бы перейти на гигабитный Ethernet, протокол все равно требует, чтобы ваш клиент простаивал несколько миллисекунд между двумя последовательными сетевыми пакетами (чтобы другие узлы тоже могли общаться).

Но гигабитный Ethernet невозможен, поскольку клиенты находятся далеко (возможно, подключены через Интернет).

Таким образом, единственный путь, который будет работать, это приблизить бизнес-код к серверу. Наиболее простым решением будет установить клиенты на маленьких коробках в той же локальной сети, что и сервер, и использовать VNC или аналогичный протокол для удаленного доступа к ним.

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

Answer 3

Либо реорганизуйте код основным способом, либо перепишите все приложение. Если ваш менеджер скажет, что это займет много времени, добавьте индикатор выполнения, чтобы пользователь думал, что он идет быстрее.

Answer 4

Я бы посоветовал сделать как можно большую часть этого процесса асинхронной. Должны ли клиенты иметь оперативный ответ на обработку? Если нет, вы можете перейти к концепции MOM (Messaging Oriented Middleware) и поместить очереди / темы JMS между клиентом и сервером.

Клиент может публиковать записи для обработки в очереди, которую отслеживает сервер. После завершения обработки сервер помещает результаты в очередь для ответа, которую будет прослушивать клиент. Это вызвало бы рефакторинг, но, если ваш код слабо связан, он не должен быть ужасно агрессивным.

Answer 5

Стив Соудерс (Steve Souders) - «Высокопроизводительные веб-сайты: необходимые знания для передовых инженеров» - действительно хорошая книга на эту тему. Смотрите здесь .

Сайт Стива здесь .

Answer 6

Не уверен, но похоже, у вас есть данные в файле размером 50 МБ, которые вы хотите проверить / обработать и сохранить в базе данных. Это правильно?

Почему клиент может просто передать файл на сервер, а сервер выполняет задачу проверки / обработки и сохраняет ее в базе данных? Это не приведет к сетевым вызовам, кроме передачи данных файла на сервер.

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

Answer 7

Пожалуй, лучшее, что можно сделать, - это лучше понять, как работает инфраструктура

1. Почему файлы такие большие?
2. Должны быть отправлены все файлы, или вы могли бы получить, отправив только необходимые детали для обработки
3. Что это за сетевые вызовы? Они все необходимы? Если да, можно ли объединить вызовы в один вызов?

Answer 8

Провели ли вы какие-либо измерения относительного времени, потребляемого различными частями операции? Я бы ничего не трогал, пока вы не измерили, сколько времени занимают отдельные процессы.

I подозреваю ключом является проблема с задержкой. Но я бы сначала измерил и определил это, прежде чем искать какие-либо решения.

Answer 9

- Сделать сервер без сохранения состояния, если это еще не так

-Просмотр легких протоколов, таких как Hessian

- Задержка - это, вероятно, ваше узкое место, рассмотрите возможность использования кэша в клиентах и ​​считывания больших кусков данных, 1000 циклов обмена - это огромная нагрузка.

-Рассмотрение рефакторинга клиента, чтобы он мог работать локально и синхронизироваться в фоновом режиме

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

Answer 10

Если вы не можете изменить протокол, хотя бы измените полезные данные:

1) Это звучит как закрытая система. Если да, то нет необходимости использовать обобщенный Serializable протокол. Переключитесь на Externalizable и запишите минимальные данные, необходимые для захвата состояния объекта для банковского перевода.

2) Сжатие данных, отправляемых с сервера на клиент. Помимо состояния объекта в (1), вы также должны уменьшить количество больших двоичных объектов (файлов), которые вы перемещаете по сети.

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