对高性能Web服务的研究笔记

策略：

静态化：根据文件以及内容特征以多个时间框架为间隔进行相对静态化以及如何实现绝对静态化；

缓存：多级以及区分对象，策略。工具有：SQUID，MEMCACHE等；

镜像：linux中的rsync或ftp或其它；

集群：两种方式，分工合作与机群；

内容更新：在字节级别上控制双向通信的流量负载；删减一切不必要的通信过程和通信内容。

涉及到的技术：

JAVA 异步、非阻塞通信：NIO, IO, 缓冲区与通道机制，两者缓冲机制的区别。从提供者的角度看，NIO仍然是一种同步通信提供者，但是提供了一种非阻塞的调用方法。有文章提到底层实现其实是LINUX 的 SELECTOR和 WINDOWS 的 WAITFOROBJECT，估计都是通过在内核另起线程专司轮询其职实现的。目前理解，除去SUN自己提供的NIO，肯定有第三方的通信包，提供非阻塞，异步的通信职能。有待进一步探索！！！

虚拟机：SUN为SERVER端与CLIENT端提供了不一样的HOTSPOT，以适应不同并发级别上的字节码执行环境。字节码的优化。动态与静态编译各自的优缺点；

关于NIO与IO的性能孰优孰劣的网上争论，焦点似乎只在如何使用线程。我的观点是当涉及到高性能的时候，不要总是以理想化的思维方式去思考问题。我们之所以研究性能，正是因为我们遇到了障碍。比方说，不能响应，或者系统崩溃，或者慢。而发生这些都是因为遇到了资源甁颈。所以，正确的思考角度应该是从资源出发的。处理器、内存与外存，以及网卡，都可以成为资源的甁颈。有一种观点，认为为每个处理器核分配一个（或半个）线程是一种合理的线程策略。我认为一个肯定不行，因为所有的核几乎不可能在同一个时间只处理同一种任务（请求接收）。即使这样的情况发生了，它也不是最佳的处理模式，因为在这种情况下，系统所有的能力将被用来承担请求的接收，已经没有空余的能力可以完成请求接收以后接下来的任务。而如果接下来的任务不能被完成的话，所有的线程都将被阻塞并且被阻塞的线程堆栈将最终达到系统极限而至系统再不能响应任何新的请求。所以，为每个核分配少于一个线程，把剩下来的处理器资源留给其它任务，也许才是真正可行的策略。但是有一个事实必须被承认，那就是任何系统只能承担有限的请求负载。在承认这个事实的基础上，设计目标可以变得更明确，那就是系统处理能力的最大化。

如果说异步IO因为减少了接收线程的数量所以节省了一部分系统资源的话，根本原因其实在于线程的使用策略是正确的。其实，多于处理器核（或流水线）的并发线程数量根本就没有任何意义。

在长连接的情况下，为每个会话分配一个线程的思想看起来好象跟为每个请求分配一个线程的思想差不多。其实浪费了响应包从服务器送到客户机加上客户机发出第二个请求并送到服务器即一个往返长度的时间。我相信，在大多数情况下，这个时间都是以秒或者分秒为计算的时间。对于内存短缺而非处理器资源短缺型应用来说，在高并发的情况下，长连接节省下来的连接开销肯定要远小于它占着茅坑不拉屎所造成的损失大得多。

后面要接着研究的是MINA，ACE，JAWS。这些都是目前非常优秀的IO框架。

LINUX 下面的 SELECTOR 与 WINDOWS 下面的 WAITFOROBJECT 也是需要继续研究的东西。

在服务器推技术上，有个COMET PUSHLET也要看。好象是使用AJAX轮询或者IFRAME(HTMLFILE) 实现推技术模拟。

负载均衡方面，在LINUX上面有一个LVS即LINUX虚拟服务器，使用了NAT, IP TUNNEL， DIRECT ROUTING 三种模型进行请求路由，即第四层交换。这也是需要好好研究的东西。