|
|
| http://www.hbdxs.com 2006-8-18 14:01:47 来源：网络收集 点击 |
|
|
理论上的服务器（即软件意义上的服务器）
网站决策者对web服务器提出的目标一直都是非常清晰的，那就是：速度、效率、可靠性、可用性和可量测性。
“速度”是服务器赢得网站内容提供方和网站用户双方满意的关键因素（对于站点页面装载打开速度，前者比后者更敏感）。速度与可量测性是密切相关的，因为光有速度并不足以迅速地对一个访问请求作出响应——更何况，网站要迅速对上百万数量的访问请求提供服务。
服务器的硬件配置规格可以决定能在同一时间访问网站的用户的最大固定数量（主要是由最大可用内存空间大小决定）。你也可以通过执行web应用对该数值进行定义。因此，如要使网站支持更大数量的用户（或访问请求），关键是减少服务器处理每一请求所占用的时间。越迅速地结束处理当前这个请求，就能越迅速地开始处理下一个请求。
影响处理一个访问请求所需的时间和资源数量的因素有很多。这就是“效率”切入并发挥作用的地方。每一个访问连接（connection）将占用服务器一定大小的内存空间。具体占用多大内存，取决于HTTP服务器和web应用的执行情况。另外一个影响因素是建立一个连接需要耗用的时间长短以及此连接是用来传输单个文件，还是用来传输一个完整页面。
对web性能起最重要作用的一个因素也许就是应用的内容创建效率。对该因素的控制，主要是由应用开发商来完成的。比如：系统要对一个访问请求作出响应，会生成大批量指向数据库的复杂查询吗？如果是这样的话，这些查询可以存放在缓冲区吗？存入缓冲区的这一过程在动态的应用中是怎样进行的？是将数据存入缓冲区，还是就把HTML的单视图输出存入缓冲区？再强调一下，这里提到的大部分问题都是由应用开发商来具体实施的，只有他们才能回答。
相反，还有一个应用开发商难以调控的重要因素，那就是“网络”因素。你能够确保服务器高带宽地接入互联网，可是你却不能保证所有用户的客户端系统都能以同样的接入方式访问站点。客户机和“网络”因素也象内容创建一样，能够影响每一个访问请求的服务器处理时间长短以及web应用的总体效率。
谈谈用户用典型的modem（调制解调器）拨号上网方式。这种方式下，用户可以获得最大为5 KB/s的下载速度。如果当前用户试图下载大小约为200KB（以今天的标准来看，这个数字相当小了）的通用消息板块索引页面（general mesage board index page），那么要完成这个单线程下载至少得用40秒的时间。这40秒钟主要是服务器端将所有和访问站点的连接有关的资源捆绑起来而占用的时间。在这种连接方式下，即便是一个体积更小、约35KB大小的HTML页面也将需要7秒的时间才能完成传输，正常打开。7秒比之40秒，显然算是比较快的了。如果有几百个用户同时访问，那么请把这个数字叠加起来，你会发现你的服务器在短期内将会迅速地耗尽资源。
HTML页面压缩比较
页面类型 字节数（byte） 5 KB/s速率下的传输时间（秒）
前端页面 未压缩 41,665 8.14
经压缩 8,744 1.71
通用消息索引 未压缩 168,353 32.88
经压缩 13,478 2.63
为了最大地提高网络效率，我们可以压缩站点的输出数据流，也就是压缩站点。HTML页面经常重复，因此，该类页面的压缩率常常很高。上文所述的200KB的访问请求在5 KB/s连接速率下需要40秒的连续传输。如果这个200KB的访问请求能被压缩成15KB，那么只需要3秒的传输时间。当然，要压缩输出数据流，服务器会消耗一些运算时间，但这显然是次要的，因为与几毫秒的压缩时间相比，我们能够为服务器和客户机节约37秒的时间。这还意味着，服务器能够在同一时间片内，支持更多的用户并节省带宽。另一相对较小的35KB页面也许可以压缩到3KB或者4KB，也就是说，modem的传输时间将从7秒锐减到1秒。
现实中的服务器
与新服务器配合的是一款新的基于Java servlets和JSP（Java Server Pages）的服务器应用。另外，Servlet容器（或者说web应用的运行平台）采用的是Caucho Technology公司（http://www.caucho.com/）的Resin。由于Resin也直接处理HTTP请求，整个服务器应用除了数据库外，都跑在JAVA虚拟机（JVM）上。Resin是一个具有高性能的J2EE应用服务器，得到众多网站的广泛应用，包括Altavista和Half.com。由于Resin的可靠性和高性能，因此Resin/J2EE平台是站点的不二之选。
那么，这一新的web应用对新服务器来说，实际上意味着什么呢？为了测试网站软件部分的性能，这里搜集了大量的服务器运行数据。以下就是一个CPU占用率曲线图，标示了该网站web应用（Java）和数据库在5秒钟内的CPU占用率（每隔1分钟记录一次）。这些数据是在2001年10月16日从中午到午夜这段时间搜集的。当日，服务器处理了来自23979个不同用户发出的392526个访问请求。
由上图你可以看见，web应用和数据库的CPU占用率平均来说都很低。尽管可能缘于服务器运行了一些更为复杂，但不常作的查询操作，数据库对CPU的占用率存在几个高达30%和40%的峰值，但是，web应用和数据库两者对CPU的占用率均值都在10%到15%之间。需要注意的是，该曲线图实际上记录了大量的的测试数据（700个以上）。
这里还有一个有趣的曲线图，记录的是web应用的线程数量。该图标示了5秒钟内的并发线程数量（也是每隔1分钟记录一次）。
在该图中，你可以清晰地看到当天的线程总数是怎样随着负载的变化而变化的。其中，并发线程的最大数量为117。在晚上18时以前，线程的平均数量大概在90到100之间，随着时间的推移，线程数量降到了80多，到了午夜前后，最终减少到75左右。
Web应用（整个Java进程）占用的常驻内存大小全天保持在260MB左右（实际上并无远超这个数字的情况）。这一数字能保持相对稳定是因为系统的缓冲区大小是固定的，同时，web应用占用的内存空间也没有随着时间的推移而膨胀（也即没有发生内存渗露的情况）。数据库在初始化之后，获得了固定的内存空间（它被设置成占用512MB内存）。目前，该服务器报告仍有约1GB未分配的剩余内存空间。也就是说，新系统还有很大的扩展空间。
持久的web应用
改用基于Java的web应用是站点软件系统向前的一大飞跃。该网站原先在Apache /PHP平台上跑的应用仅仅是服务器应请求而解释运行的单独脚本，经更换平台后，这一新的站点自身就成为了一个完善的、运行流畅的多线程应用。当某个访问请求被提交后，web应用就会生成一个新的线程来处理这一请求。如果需要的话，数据库连接将从一个由该应用维护的共享连接池中被分配和指定。
在该网站原来的解释运行脚本情况下，程序是在一种空闲和无状态信息的情况下编译执行的。只有在对脚本发出请求的时候，脚本才会运行。同时，在线程或组件之间没有任何的通讯，也没有共享的资源。
网站的软件平台使它有可能建立真正有状态信息(stateful)的应用（能够创建和共享全球通用的资源）。比如，站点的消息论坛（message forums）使用了一个共享的消息索引缓冲区（shared message index cache），能够有目的地将数据库从几乎所有的“读”操作中释放出来。这一缓冲区在内存中对所有的线程都是共享的，同时，只有在对数据库作出一个“写”操作（如新的发贴、编辑或删除）时，该缓冲区才会得到刷新。在PHP或PERL等环境下，这样的缓冲区是很难实现的，因为不可能在某个解释运行脚本的不同实例（instance）中共享固定不变的对象(object)。
持久的智能缓冲区
站点还使用了另外一个为新的发贴操作、论坛消息、甚至是象本文一样的文章而准备的按需使用（on-demand） 缓冲区。当收到一个按特定规格查看特定文章、消息或新闻的请求后，该站点的web应用首先会查看这个缓冲区，看看是否有这个对象。如果它找到了这个对象，应用就会重新获取这个对象，并将该页面发往客户端，最后归还对象。这3个动作只需几毫秒的时间。如果该对象没有放在缓冲区内，那么系统就会指定一个connection对象并查询数据库。查询的结果将会储存在缓冲区内，以备下次需要它的时候使用。缓冲区有效期（cache expiration）是通过最近最少使用算法（LRU）来计算的，这就是为什么最不经常被访问的对象随着时间推移，会逐渐期满并退出缓冲区的原因。
这些类型的缓冲区真正的优点在于他们能在不牺牲站点动态特性的同时，最大地提高系统的性能。由HTTP服务器实现的更为传统的缓冲解决方案能够将某个特定请求的全部输出储放在缓冲区，但是它没有可操作性，因为在这种方案下，系统管理员需要根据用户指定的规格去具体定制输出。
在留言板系统（message board）情况下，颜色方案（color scheme）和索引显示长度（index display length）可由用户进行设置。系统还允许用户设置成将日期显示在其本地的时间区域（timezone）中。这确实可以做到的，因为系统是将数据自身（而不是输出）存放在缓冲区。最后要说的是，这一系统架构把两种优势都综合起来了：一是由缓冲带来的极佳性能；二是动态页面生成所具有的灵活性和可定制性。
进程和线程
进程是现代化软件的基本构成组件。本质上说，一个进程就是一个拥有自己的虚拟地址空间的单独运行程序。当操作系统改变当前的活动进程（active process）时，就会出现一个系统状态切换操作（a context switch）。由于每一个进程都有它们自己的虚拟地址空间，地址转换映射表（address translation map）就会在上下文切换过程中相应地发生改变。
在一个进程内，也有可能存在多个执行线程。线程与进程是类似的，通过线程，软件开发商能够为他们的软
|
|
|
|
|
|
