如何提高客户端-服务器架构应用程序的性能？
我们有一个基于客户端-服务器架构的产品。 有关所使用的技术堆栈的一些详细信息。
- 客户端 - Java Swing
- 服务器 - RMI
- Java 数据库 - Oracle
客户端位于世界不同地方，但 java 服务器和服务器位于世界各地。 oracle数据库位于瑞典的同一台机器上。 因此，存在大量网络延迟。 位于遥远地点的客户端的性能很差。 该应用程序用于处理大小超过50MB的文件。 每个操作一般需要大约超过 1000 次网络调用。
根据您的经验，您如何解决这个问题并提高性能？
编辑：回答几个问题
- 文件包含需要处理和更新到数据库的实际业务数据，不能部分发送。
- 一些网络调用可以批量处理，但这需要对代码进行重大重构。 这是一个非常古老的应用程序，编写于 2001 年。应用程序的设计是这样的，服务器保存所有服务，并且它们可以跨代码重用，业务逻辑写在客户端。 因此，该业务逻辑多次调用服务器，因此是一个天文数字。
-斯内哈尔
We have a product built on the Client-Server architecture. Some details about the technology stack used.
- Client - Java Swing
- Server - RMI
- Java Database - Oracle
The clients are located at different parts of the world but the java server & the oracle database are located on the same machine in Sweden. Because of this there is a lot of network latency. The clients located at distant locations have terrible performance. The application is used for processing files with the size over 50MB. Each operation in general requires about over 1000 Network calls.
Based on your experience, how do you tackle this problem and improve the performance?
EDIT: To answer a few questions
- Files contains the actual business data which needs to be processed and updated to the database cannot be sent in part.
- Some of the network calls could be batched but it would require major refactoring of the code. This is a very old application written way back in 2001. And the design of the application is such that, the server holds all the services and they are made reusable across the code and the business logic is written on the client side. So, this business logic calls server numerous times and hence the astronomical figure.
-Snehal
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
减少往返次数
单次操作 1000 次往返是一个天文数字。 你绝对不应该看到这些数字。
但对于 50MB 的文件，您仍然遇到问题。 在这种情况下，您要么需要找到一种方法来提高传输效率（仅传输两个相似文件之间的增量？），要么采用某种缓存。
WAN 流量正在扼杀您的应用程序，听起来您需要进行重大重构。
Decrease your number of round trips
1000 round trips for a single operation is an astronomic figure. No way you should be seeing those numbers.
You still have a problem though with the 50MB files. In which case, you will either need to find a way to make the transfer more efficient (transfer only deltas between two similar files?), or employ caching of some sort.
The WAN traffic is killing your app, and it sounds like you have major refactoring to do.
通过网络发送大文件和大量请求会花费大量时间。 时期。 即使您可以升级到千兆位以太网，该协议仍然要求您的客户端在两个连续的网络数据包之间空闲几毫秒（以便其他主机也有机会进行通信）。
但千兆位以太网不可行，因为客户端距离很远（可能通过互联网连接）。
因此，唯一可行的方法是将业务代码移至更靠近服务器的位置。 最简单的解决方案是将客户端安装在与服务器位于同一 LAN 中的小盒子上，并使用 VNC 或类似协议远程访问它们。
下一个层次是将客户端分为业务层和显示层。 将业务层变成服务，并将显示层安装在客户端上。 这样，数据仅在（快速）内联网上传输。 当结果准备好显示时，客户端仅获得结果（少量数据）。
Sending big files and lot of requests over the net costs a lot of time. Period. Even if you could upgrade to gigabit Ethernet, the protocol still demands that your client idles a few milliseconds between two consecutive network packets (so other hosts get a chance to talk, too).
But gigabit Ethernet is not feasible since the clients are far away (probably connected via the Internet).
So the only path which will work is to move the business code closer to the server. The most simple solution will be to install the clients on little boxes in the same LAN as the server and use VNC or a similar protocol to access them remotely.
The next level would be to cut the clients into a business layer and a display layer. Turn the business layer into a service and install the display layer on the clients. This way, data is only pushed around on the (fast) intranet. When the results are ready for display, the clients get only the results (little data).
- 如果还没有这种情况，则使服务器无状态
- 考虑更轻的远程协议，例如 Hessian
- 延迟可能是你的瓶颈，考虑在客户端中使用缓存并读取更大的数据块，1000 次往返是巨大的负载。
- 考虑重构客户端，使其能够在本地工作并在后台同步
- 使用分析器查看应用程序花费最多时间的地方并对其进行优化
-Make server stateless if it is not yet the case
-Consider lighter remote protocols such as Hessian
-Latency is probably your bottle neck, consider using cache in clients and read bigger chunks of data, 1000 round trips is huge load.
-Consider refactoring the client to make it able to work locally and have it synchronized in the background
-Use a profiler to see where the application spends most time and optimize that
您是否对操作的不同部分的相对时间消耗进行过测量？ 在您测量各个流程需要多长时间之前，我不会碰任何东西。
我怀疑延迟问题是关键。 但在考虑任何解决方案之前，我会首先衡量并确定这一点。
Have you performed any measurements of the relative time consumption of different parts of the operation ? I wouldn't touch anything until you've measured how long individual processes take.
I suspect the latency issue is the key. But I would measure and determine this first, before looking at any solutions.
也许最好的办法是更好地了解基础设施的工作原理
Perhaps the best thing to do would be to get a better understanding of how the infrastrucure works
不确定，但看起来您在 50 MB 文件中包含一些数据，您想要验证/处理这些数据并将其存储在数据库中。 这是对的吗？
为什么客户端可以简单地将文件传递给服务器，然后服务器执行验证/处理任务并将其存储在数据库中？ 除了将文件数据传递到服务器之外，这将不会有任何网络调用。
另一种可能性是，如果您可以在一次调用中组合多个操作，即会话外观模式。
Not sure but looks like you have some data in the 50 MB file which you want to validate/process and store in database. Is it correct?
Why can the client simply pass the file to server and the server do the validate/process task and store in the database? This will there are no network calls except passing the file data to server.
Other possibility is if you can club multiple operations in one call i.e. a session facade pattern.
Steve Souders 的《高性能网站：前端工程师的基本知识》是一本关于这方面的好书。 请参阅此处。
Steve 的网站位于此处。
"High Performance Web Sites: Essential Knowledge for Front-End Engineers" by Steve Souders is a really good book on this. See here.
Steve's website is here.
我建议尽可能多地使这个过程异步。 客户是否需要实时响应处理？ 如果没有，您可以转向 MOM（面向消息的中间件）概念，并将 JMS 队列/主题放置在客户端和服务器之间。
客户端可以将要处理的记录发布到服务器正在监视的队列中。 处理完成后，服务器会将结果放入客户端将侦听的回复队列中。 这将强制进行重构，但假设您的代码是松散耦合的，那么它不应该具有太大的侵入性。
I would suggest looking to making as much of this process asynchronous as possible. Do the clients need to have real time response to the processing? If not, you could move to a MOM (Messaging Oriented Middleware) concept and place JMS queues/topics in between the client and the server.
The client could post records to be processed onto a queue that the server is monitoring. Once processing is complete, the server would place the results to a reply-to queue that a client would be listening on. This would force a refactor, but assuming your code is loosely coupled, it should not be terribly invasive.
要么主要重构代码，要么重写整个应用程序。 如果您的经理说这需要很长时间，请添加一个进度条，以便用户认为进度更快。
Either refactor the code in a major way or rewrite the entire app. If your manager says that will take to long add a progress bar so the user thinks it goes faster.
每个操作需要 1000 个请求，这很多了！
这将杀死任何服务器。
这通常是一个无法通过添加更多硬件来解决的问题
或添加更多带宽。
这是一个设计问题。
不管怎样，我会安装一个分析器来查看
服务器状态（内存消耗、CPU 等）。
看一下 lambda 探针 (http://www.lambdaprobe.org)
Each operation requires 1000 requests is a lot!
This will kill any server.
This is typically a problem which cannot be solved by adding more hardware
or adding more bandwith.
This is a design problem.
Anyway I would install a profiler in order to see
the server status (memory consumption, cpu, etc).
Take a look at lambda probe (http://www.lambdaprobe.org)
RMI 是一个非常昂贵的协议。 我会考虑更换它。
RMI is a very expensive protocol. I would look at replacing it.
如果您无法更改协议，至少更改有效负载：
1）这听起来像是一个封闭的系统。 如果是，则无需使用通用串行化协议。 切换到外部化并写入捕获对象状态以进行电汇传输所需的最少数据。
2) 压缩从服务器发送到客户端的数据。 除了 (1) 中的对象状态之外，您还应该减少在网络上移动的数据 blob（“文件”）。
除此之外（这显然取决于系统），您应该探索前向缓存节点。 在许多应用程序中，存在域实体访问的模式。 如果存在可以利用的地理访问模式，您应该能够轻松创建新的代理节点，它们是远程服务器的客户端，然后充当附近 (rmi) 客户端的 (rmi) 服务器。
If you can not change the protocol, at least change the payloads:
1) This sounds like a closed system. If yes, there is no need to use generalized Serializable protocol. Switch to Externalizable and write the minimal data required to capture object state for wire transfer.
2) Compress the data that is sent from server to client. Beyond object state in (1), you should also reduce the data blobs ("files") that you are moving around the net.
Beyond that (and this obviously depends on the system) you should explore forward caching nodes. In many applications there is a pattern to domain entity access. If there is geographic access patterns that can be exploited, you should be able to trivially create new proxy nodes that are clients to the remote server and then act as a (rmi) server to nearby (rmi) clients.