中间件如何影响系统的性能指标（如吞吐量、响应时间、交易成功率）？

业务系统的性能上不去（具体表现在吞吐量低，响应时间长）等现象，不少是应用中间件导致的。
例如系统的处理能力上不去，加了WAS并发也不管用，cpu利用率上不去。然后仔细一问，加了什么并发，回答说“负责去MQ队列读消息的应用进程数”，我问“连数据库的jdbc连接池数量呢”，回答说“不知道”。这说明不少人对中间件的参数以及它的作用并不是很清楚。

跑在应用中间件上的应用是委托“中间件”来处理“应用”与外界的一切联系，比如
1）有请求进来，我有多少个session来服务于请求
2）应用需要读写数据库，数据库连接由应用中间件负责，并且还放置了连接池。
3）应用需要多少内存，由中间件定制
4）应用需要做GC，由中间件定制
5）等等

可以把这个中介（中间件）看做是应用和外界联系的一个管子，或者多个管子（每个管子负责某一方面的联系）。

如果这个管子太细，比如数据库jdbc连接池的太小，就不足以满足应用与数据库的频繁沟通。这样前端就会积压大量的业务等待处理，而后端又不给力，导致了等待“数据库连接”的时间变得特别长（也就是响应时间增加），响应时间增加后，单位时间呃逆处理的业务数量减少，也就是吞吐量下降。

上面的例子是前面的管子太粗，把大量的请求放进来，跑到了应用服务器上，而后面的管子（数据库连接）太细。
假如说这时候把后面的管子放的足够大会出现什么结果呢？ 也许性能优化的还不错，也许就出现灾难（也就是所谓的负优化），本来一秒钟还能处理10笔业务，结果，大量业务冲到数据库上，把数据库压瘫了，一笔业务能也处理不了了。

竞争剧烈的时候（大量业务抢一个或几个小管子）就会有等待超时（例如设置了进程等待资源超过xx秒就超时，进程自杀），或者僵死（拥有A资源，等待B资源，而另一个业务拥有B资源，等待A资源），这就造成了交易失败。这也是为什么所有系统在吞吐量高到一定程度的时候就会出现交易成功率不再是100%的现象。

再比如设置GC太频繁，会导致应用总会有停顿，停下来做那个GC，而忘了应该干的正经事。