系统架构性能篇章1（应用系统性能1）Java开发Java经验技巧.docVIP

系统架构■性能篇章1 （应用系统性能1）?编程 开发技术 系统架构-性能篇章1 （应用系统性能1） 原文出处：xieyu_zy 在前面的文章中，说了很多JVM和数据库方面的东西，我所描述的内容人多偏重 于技术本身，和实际的业务系统结合的比较少，本文开始进入实际的系统设计中 应当注意的方方而而（文章偏重于访问量高，但是每次访问量并不是很大的系 统），而偏重点在于性能和效率本身，由于这个知识涉及的基础和面很广，所以 建议是先看下以前写的内容或自己有一定的基础来才开始接触比较好，另外本文 也不能诠释性能的关键，从一个应用系统询端到后端涉及的部分非常多，本文也 只会说明其中一部分，后续的部分我们再继续说；下面我们想一下一个web应用 绝大部分请求的整个过程：client发出请求-＞server开始响应并创建请求对象 及反馈对彖-＞如果没有用户对彖就创建session信息-＞调用业务代码-＞业务代 码分层组织数据-〉调用数据（从某个远程或数据库或文件等）-〉开始组织输出数 据-〉反馈数据开始通过模板引擎进行渲染-〉渲染完成未静态文件向客户端进行 输出-〉待客户端接收完成结束掉请求对象（这种请求针对短连接，长连接有所区 别）。 就从前端说起吧，说下一下儿个内容： 1、 线程数量 2、 内容输出 3、 线程上下文切换 4、 内存 1.首先说下线程数量，线程数量很多人认为在配置服务器的线程数量时认为越多 越好，各大网站上很多人也给出了自己的测试数据，也有人说了每个CPU配置多 少线程为合适（比如有人说过每个CPU给25个线程较为合适）,但是没有一个 明确的为什么，其实这个要和CPU本身的运行效率和上来说明，并非一概而论的, 也需要考虑每个请求所持冇的CPU开销大小以及其处丁?非Running状态的时间来 说明，线程配置得过多，其实往往会形成CPU的征用调度问题，要比较恰当将 CPU用满才是性能的最佳状态（说到线程就不得不说下CPU,因为线程就是消耗 CPU的，其本身持冇的内存片段非常小，前面文章已经说明了它的内存使用情况, 所以我们主要是讨论它与CPUZ间的关系）。 首先内存到CPU的延迟在儿十纳秒，虽然CPU内部的三级缓存比这个更加小，但 是儿乎对于我们所能识别的时间來讲可以被忽略；另外内存与CPU Z间的带宽也 是以最少几百M每秒的速度通信，所以对于内存与CPU交互数据的吋间开销对于 常规的高并发小请求的应用客户忽略掉，我们只计算本身的计算延迟开销以及非 计算的等待开销，这些都一般会用毫秒来计算，相互Z间是用10e6的级别来衡 量，所以前者可以忽略，我们可以认为处于running的时间就是CPU实际执行的 吋间，因为这种短暂的吋间也很难监控出来到底用了多久。 那么首先可以将线程的运行状态划分为两大类，就是：运行与等待，我们不考虑 被释放的情况，因为线程池一?般不会释放线程，至于等待有很多种，我们都认为 它是等待就可以了；为什么是这两种呢，这两种正好对应了 CPU是否在被使用， running状态的线程就在持有CPU的占用，等待的就处于没有使用CPU。 再明确一个概念，一个常规的web请求,后台对应一个线程对它的请求进行处理, 同一个线程在同一个吋间片上只能请求一个CPU为他进行处理，也就是说我们可 以认为它不论请求过多少次CPU、不论请求了多少个CPU,只要这些CPU的型号 是一样的，我们就可以认为它是请求的一个CPU（注意这里的CPU不包含多个com 的情况，因为多个core的CPU只能说明这个CPU的处理速度可以接近丁?多个CPU 的速度，而真正对线程的请求来讲，它认为这是一个CPU,在主板上也是一个插 槽，所以计算CPU的吋候不考虑多核心）。 最后明确线程在什么情况下会发生等待，比如读取数据库吋，数据库尚未反馈内 容Z前，该线程是不会占用CPU的，只会处理等待；类似的是向客户端输出、线 程为了去持冇锁的等待一系列的情况。 此时一个线程过來如果一个线程毫无等待（这种情况不存在，只是一种假设）， 不论它处理多久，处理时间长度多长，此吋如果只有一个CPU,那么这个应用服 务器只需要一个1个线程就足以支撑，因为线程没有等待，那么CPU就没有停止 运行，1个线程处理完这个请求后，接着就处理下一个请求，CPU —直是满的， 也儿乎没有太大的征用，此时1个线程就是最佳的，如果是多个同型号的CPU, 那么就是CPU数量的线程是最佳的；不过这个例了比较极端，在很多类似的情况 下，大家喜欢用CPU+1或CPU-1来完成对类似情况的线程设置，为了保证一些特 殊情况的发生。 那么考虑卜?实际的情况，如杲有等待，这个等待不是锁等待的（因为锁等待有瓶 颈，瓶颈在丁 CPU的个数对于他们无效）,应该如何考虑呢？我们此时来考虑下 这个等待的时间长度应该如何去考虑，