《Ourlinux》杂志

一般来说，组成Web站点体系结构有如下几个基本元素。

浏览器

因为Web浏览器标准、简单且普遍使用，所以它可以称得上是一个接近理想状态的图形用户接口（Graphical User Interface，GUI）。
目前比较流行的浏览器有：IE，firefox，opera，safari等，所以必须要了解其的相关特性，这也利于更好的利用这些特性来做相关架构的设计。

负载均衡

最简单的莫属DNS轮询（Round Robin DNS）方式了，但是不建议使用，因为下面的三个原因迫使你特别小心：
1. Round Robin DNS无法实现真正的负载均衡，但是在一些简单情况下还是能够均衡负载。真正的负载均衡是监测服务器的使用情况，以及根据该使用情况来分配连接，以便能始终将连接分配给那些有足够的容量来处理这些连接的服务器。
当Round Robin集中的一台服务器比其他服务器慢很多时，就会产生一种称为”护航（convoying）“的特殊情况，这时用户会列队等待速度较慢的服务器，而较快的服务器则未被使用。真正的负载均衡不会出现这样的问题。
2. RRDNS不会视图解决服务器的失效问题。用户仍然会被引导到失效的服务器上。真正的负载均衡可以提高站点的可用性，因为如果一台服务器出现故障，那么其他的服务器会自动接过该服务器的负载。
3. RRDNS很难保持用户的状态，特别是使用session的业务，比如某个用户在发表文章或者回复的时候，应用程序会对该用户的session保存在当前的服务器上，但是当用户写好文章或者回复开始提交后，因为RRDNS，结果发现用户提交到了另外的服务器上，因为新的服务器上没有用户的session，提示用户未登陆等警告信息，所以会导致提交失败。
很多情况，情况当要从dns里删除失效的IP时，会发现DNS的更新非常慢，因为很多LOCAL DNS并不遵循相关规范，这样有许多用户的LOCAL DNS服务器的缓存里仍会保留这个失效的IP，而且保留的时候甚至会很久，在国内特别是小的ISP常会这么做。

IP级别的负载均衡
这里常见的软件的实现方式有LVS，值得骄傲的是LVS是由国人章文嵩开发的，其简单高效，当然也需要配合其他的HA软件来实现”三H“。通过IP级别的负载均衡可以避免上述的RRDNS弊端。

当然也可以使用硬件均衡设备。

Web服务器

目前常用开源的Web服务器有：Apache、Nginx、Lighttpd等。
Web服务器的内容和日志应当分开保存到各自专用的磁盘上，这样可以避免他们相互干扰。

中间件

任何与一端的Web服务器和另一端的数据库交互的软件都可以被成为中间件。中间件的好处可以使结构清晰简单，可以提高整体性能。

数据库

数据库表可以通过某种方式被定义、镜像、分割、部署，以使之发挥最大的性能。数据库的优化是们深奥的学问，一个好的数据库管理员（Database Administrator，DBA）身价也是不菲的。
目前常见的DB有：mysql、oracle等。

虽然Web站点体系基本上是上述几个方面，但是影响Web性能确有更多的因素，只要把握上述几个方面，逐步排除和优化，我想结果一定不会差。

做个标记:)

Httperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.

Httperf 是一个高效的 http 压力测试工具，使用它可以模拟出超过1千的并发访问，能充分测试出 web server 的性能。而之前使用的 siege 测试工具则未能突破 500 个并发测试（如果您知道如何可以实现，请告诉我）

(more…)

1. 需要多大的带宽？

对web站点的性能来说，服务器带宽是为仪最重要的因素。实际上确定需要怎么样的带宽的数学公式非常简单：次／秒（每秒访问的次数）＊比特／次（每次访问的平均容量）＝比特／秒

2. 需要多快的服务器？

对绝大多数网站来说，处理静态文件的性能兵并不是瓶颈。
因特网上一个http传输的全部时间通常是2－20秒，其中大部分是由调制解调器和因特网带宽以及延迟限制带来的。

3. 性能参数？
   • 不要太依赖基准，除非这些基准与你实际想做的密切相关；
   • 不仅监控服务器的负载，而且监控实际的web性能，并做记录；
   • 不要进行过多的监控，否则你将成为制造问题的一份子；

每个计算机系统都有4个传统的参数：延迟、吞吐量、利用率和效率。
许多组建在利用率约为70%时性能最好。
有效性度量是计算单位开销所或得的性能，这通常叫做成本效率（cost efficiency）。优化性能就是增加成本效率的艺术，即充分利用所花的每一分钱。

4. 负载测试的准备工作：
   • 需要创建测试用的用户帐号
   • 数据表饿内容需要与用于生产的系统相兼容
   • 用户测试的机器与生产的机器之间的系统参数必须同步
   • 要测试收集一组实际的url
   • 模拟客户端连接速度

   可以用：
[shell]
time lynx -source http://www.ourlinux.net
[/shell]来做用户模拟连接


5. 性能分析：
   • 如果DNS是瓶颈所在，则需要调整DNS，选择更快的DNS
   • 如果连接时间是瓶颈，则一定是网络存在问题。可能是连接建立时，由于网络集线器超载次丢失了一个数据包。路由器、接口和线缆也都有可能出现问题。
   • 如果服务器静止时间是瓶颈，则服务器可能会出现某种程度的超载，更换为更好的硬件或使用更加优化的服务器应用程序或数据库即可解决这个问题。
   • 如果传输时间是瓶颈，则问题在于客户端连接速度太慢，或者是要传输饿内容过大所致。
   • 如果连接关闭是瓶颈，则仍然是网络问题。

诊断问题时，第一步是将性能分为五种类别：DNS查找时间，连接建立时间，服务器禁止时间，传输时间，还有连接关闭时间。

6. 常见问题
• 磁盘已满
• 进程缺乏文件描述符
• C指针错误
• 内存泄露
• 线程死锁
• 死进程控制了锁
• 服务器超载
• 负载均衡器检测不到故障机器
• 子网流量超载
• ptys不够用
• 数据库中的临时表不够用
• 糟糕的设备驱动程序
• 硬件故障
• 断电
• 处理故障服务器的管理员
• 包括错误文件的通配符
• 权限问题
• 路径问题
• 补丁问题
• 超载的层叠
• 监控导致运行不正常的诸多因素
• 重试会导致更多问题
• 无意间锁住了关键的表
• 在使用文件就可以解决问题时却使用数据库
• 出现问题后程序无法重新连接到数据库上
• 重启后程序无法运行
• 裂分脑综合症
• 防火墙“清除”功能会堵塞基本服务
• 由于设计的变更导致screen scraing无法运行
• 相关性
• 处理故障