吞吐量和响应性的思考

系统的性能可以从吞吐量和响应性这两个方面考察。吞吐量衡量的是“有多少”，即限定资源的情况下，能够完成多少工作。响应性衡量的是“有多快”，即单个任务的处理时间。可以说吞吐量越大，响应越快，就表示系统的性能越好。
性能的这两个方面是完全分离的，有时候甚至是矛盾的。有人说软件设计就是权衡，其实我们能在很多地方看到对吞吐量和响应性的取舍。

1. Java gc算法的选择。Java -server缺省的gc算法是Parallel Collector，能够提高吞吐量，但是当你对响应时间更看重的时候，就需要选择Concurent Mark-Sweep(CMS)。

2. 线程上下文的切换。OS在线程上下文切换的时候会有系统开销，调度程序会为每一个可运行的线程分配一个最小执行时间，这样做是为了偿还线程切换的开销，获得更多不中断的执行时间，从整体上提高吞吐量，但这是以牺牲响应性为代价的。

3. Real-Time Java
实时系统，简单的说就是，能够在指定或者确定的时间内完成任务。系统的正确性不仅取决于系统计算结果的正确性．而且取决于正确结果产生的时间。
● “When” is as important as “what”
● “A late answer is a wrong answer”
real-time并不意味着一定比非实时“快”，而是强调执行时间的可预测性。普通Java不能做到实时，GC暂停是一个很重要的原因，因为这是开发人员无法控制和预测的因素。因此在Real-Time Java中，对GC的选择就是完全偏重于响应性。我们可以看一个对比：

对于SIP(Session Initiation Protocol) Server，实时系统的吞吐量比普通系统小，但对请求处理的延迟时间小，延迟大于50ms的只占0.3%。