- 需要多大的带宽？
- 需要多快的服务器？
- 性能参数？
- 不要太依赖基准，除非这些基准与你实际想做的密切相关；
- 不仅监控服务器的负载，而且监控实际的web性能，并做记录；
- 不要进行过多的监控，否则你将成为制造问题的一份子；
- 负载测试的准备工作：
- 需要创建测试用的用户帐号
- 数据表饿内容需要与用于生产的系统相兼容
- 用户测试的机器与生产的机器之间的系统参数必须同步
- 要测试收集一组实际的url
- 模拟客户端连接速度
可以用：
[shell]
time lynx -source http://www.ourlinux.net
[/shell]来做用户模拟连接
- 性能分析：
- 如果DNS是瓶颈所在，则需要调整DNS，选择更快的DNS
- 如果连接时间是瓶颈，则一定是网络存在问题。可能是连接建立时，由于网络集线器超载次丢失了一个数据包。路由器、接口和线缆也都有可能出现问题。
- 如果服务器静止时间是瓶颈，则服务器可能会出现某种程度的超载，更换为更好的硬件或使用更加优化的服务器应用程序或数据库即可解决这个问题。
- 如果传输时间是瓶颈，则问题在于客户端连接速度太慢，或者是要传输饿内容过大所致。
- 如果连接关闭是瓶颈，则仍然是网络问题。
- 常见问题
- 磁盘已满
- 进程缺乏文件描述符
- C指针错误
- 内存泄露
- 线程死锁
- 死进程控制了锁
- 服务器超载
- 负载均衡器检测不到故障机器
- 子网流量超载
- ptys不够用
- 数据库中的临时表不够用
- 糟糕的设备驱动程序
- 硬件故障
- 断电
- 处理故障服务器的管理员
- 包括错误文件的通配符
- 权限问题
- 路径问题
- 补丁问题
- 超载的层叠
- 监控导致运行不正常的诸多因素
- 重试会导致更多问题
- 无意间锁住了关键的表
- 在使用文件就可以解决问题时却使用数据库
- 出现问题后程序无法重新连接到数据库上
- 重启后程序无法运行
- 裂分脑综合症
- 防火墙“清除”功能会堵塞基本服务
- 由于设计的变更导致screen scraing无法运行
- 相关性
- 处理故障
对web站点的性能来说，服务器带宽是为仪最重要的因素。实际上确定需要怎么样的带宽的数学公式非常简单：次／秒（每秒访问的次数）＊比特／次（每次访问的平均容量）＝比特／秒
对绝大多数网站来说，处理静态文件的性能兵并不是瓶颈。
因特网上一个http传输的全部时间通常是2－20秒，其中大部分是由调制解调器和因特网带宽以及延迟限制带来的。
每个计算机系统都有4个传统的参数：延迟、吞吐量、利用率和效率。
许多组建在利用率约为70%时性能最好。
有效性度量是计算单位开销所或得的性能，这通常叫做成本效率（cost efficiency）。优化性能就是增加成本效率的艺术，即充分利用所花的每一分钱。
诊断问题时，第一步是将性能分为五种类别：DNS查找时间，连接建立时间，服务器禁止时间，传输时间，还有连接关闭时间。