你的中间件是否只交付了中等性能？你的SOA是否只是一般般？你需要一些可行的技巧来跟踪你的堆栈。ServerSide网站最近有幸访问了Matt Brasier和Richard Walburton。Matt Brasier是《Oracle SOA Suite 11g Performance Cookbook 》一书的联合作者，及C2B2的咨询师。Richard Walburton在Devoxx UK领导着团队对Java SE的跟踪。

云不让你懒洋洋地的漂着

Brasier同意像PaaS这样的云服务可能会给你带来一些变动，尤其是围绕着扩展问题上的变化。但是他说，垃圾收集调整还是需要你自己亲自动手调整的，如果你想打造你自己的平台的话。“其实，没有‘最佳的’垃圾收集设置。处理大量小需要的工作负载将会产生大量的小项目。这种情况下，在与处理大的、持续时间较长的需求的工作负载相比，需要更多不同的垃圾收集设置。”

他说，今天的JVM在对你的猜测方面已经相当好的，但它也不会一直给出正确的答案。在优化的垃圾收集中，技术和自动化还没有功能。这意味着，如果你不自己调整的话，在云中你很有可能会过度供给或过度消费。你需要学习使用可行的监测工具，这样你就可以决定出可给哪一原则提供更多的容量。监测可以帮助你找出影响负载增加的细微差别，如临时CUP使用、每秒中请求数量、文件描述符数量，或者其它组件。了解高负载背后的事情，你可以提取出一些参数，知道Amazon EC2你的需求。

如何找出SOA套件中的问题？

找出所有问题的关键在获得系统的信息。没有一个SOA应该是事务进出的黑盒子，你不了解它里面运行如何。另外，Matt这都归结于监测和测试整个应用生命周期。为了使监测有意义，你需要知道正常与非正常的行为是什么样的。每一个系统都有资源瓶颈。从逻辑上讲，如果没有瓶颈，那么应用将会无限快速运行。常见的瓶颈区域可能包括CPC使用、内存使用、网络带宽，或资源池锁。Walburton还补充了检查GC日志或MXBeans在缩小问题范围上很有帮助。使用像VisualVM这样的工具，你可以了解到内存配置文件发生的什么事，而不只是重写代码来修复问题。Vmstat命令可能会帮助 你找出附件信息，如你是否有太多的分页。

最后，Brasier警告说反对执行测试来作为通过/失败的练习。你不能因为系统通过测试就放松警惕。进行更深入的挖掘很关键。监测可以让你看什么接近于失败，什么是热门的组件，以及哪里出现了压力。否则，你不能阻止潜在的问题。如果你一个没运行了一个小时，而且你还没意识到多运行15分钟就会使整个系统崩溃的话，那么就不算成功。

Richard指出，优化只有在特殊的问题影响了业务功能时才是必要的。他所说的很简洁，“当应用生命周期管理需要优化时，关键在于当应用无法满足业务需求时”。另一方面，如果你预先知道给定的应用不能按照你的期望来保证客户满意，以及产生利益的话，那么从一开始你就要在优化中构建。延迟可能会把用户逼疯，所以应用的时间预算特别重要。以迭代的方式（以及一些其它重要的需求）进行优化测试，可以使你更好的调整性能，且不会做的太过分，毕竟过犹不及。