问Java / C#消息传递的REST体系结构的性能

EN

这并不是真正定义得足够好，不足以做出任何度量语句；消息有多大，您访问REST服务的频率是多少，它是直接的HTTP还是需要使用SSL保护它？换句话说，您可以告诉我们有关工作负载参数的哪些信息

(我一遍又一遍地问性能问题:除非您能告诉我一些关于工作负载的信息，否则我不能--没有人能--告诉您什么能提供更好的性能。这就是为什么他们过去常说，除非你有一个实现，否则你不能考虑性能:这并不是说你不能考虑性能，而是人们通常不能或至少不会考虑工作负载。)

尽管如此，您可以简单地通过查看要交换的消息数量来做出一些好的估计，因为TCP/IP的设置时间通常支配REST。REST在这里提供了两个优点:第一，TCP/IP时间通常控制消息传输，这在Apache或lighttpd等生产web服务器中得到了很好的优化；第二，RESTful架构通过消除会话状态来增强可伸缩性。这意味着您可以使用简单的TCP/IP负载均衡器自由扩展。

我会设置一个测试来试一下，看看。我知道您要更改的应用程序的唯一部分是客户端/服务器通信。因此，分析您现在要发送的内容，并将发送消息的测试客户端/服务器设置组合在一起，这些消息代表您认为最终解决方案要做的事情(可能仅在大小/吞吐量方面具有代表性)。

正如在上一篇文章中指出的，没有足够的细节来真正判断性能会是什么样子。例如：

1. 你的消息结构/格式是相同的，只是通过超文本传输协议而不是原始套接字吗？
2. 你要发送XML数据的子集吗？处理大量XML可能是内存密集型的(例如，如果您使用的是基于DOM的approach).
3. What开销，那么您选择的REST框架将引入开销(希望很少，但目前我们不知道)。

最好的解决方案是使用(比方说) Jersey设置一些东西，然后花一些时间测试各种场景。如果您正在重新设计解决方案，那么花几天时间研究性能是值得的(更不用说功能、开发简易性等了)。

这将是非常快的，除非你有非常多的并发客户端访问这些服务器。在Java和.NET中，XML分解都变得越来越快，如果你使用的是CLR2和Java5或更高版本，那就没问题了。但当然，您仍然需要进行测试以进行验证。

我们已经在实验室测试了REST和SOAP事务，它们的速度比你想象的要快。每秒数以万计的消息。生成XML消息的少量现代CPU可以很容易地使千兆位网络饱和。换句话说，网络是瓶颈(数据传输)，而不是CPU (序列化和反序列化XML)。

而且，如果您正确地进行了软件设计，在REST不够用的非常不可能的情况下，交换消息格式层(REST =>协议)将以最小的中断获得更好的传输性能。

但在您需要去那里之前，您将能够向思科支付一些资金，并获得更多净空空间。