昨天在群里看到朋友分享的《提升可伸缩性的八项最佳实践》个人认为核心是减少延迟！

评价性能参数有以下4个指标：

1. 延迟
2. 吞吐量
3. 利用率
4. 效率

在排查问题或者设计的时候，如果将所有涉及到有延迟的地方全部整理出来，然后逐个解决延迟高的点，这样实践的点就会更多，这样也就提升了性能！

S2：性能参数

每个计算机系统都有4个传统的参数：

• 延迟

• 吞吐量

• 利用率

• 效率

优化系统性能就是要减少延迟、增加其他3个参数的值。尽管这个定义很直观，但优化本身并不直观，因为这些参数彼此之间可以互相消长，而且它们会随时间、服务内容种类已经许多其他环境改变而改变。另外，对某个机构的目标来说，有些性能参数比其他参数重要。 Read more »

四.性能监控

优化Web站点的首要任务就是对该站点进行监控，以便了解其模式和趋势。从监控中可以获知监控是否有助于站点。而且为监控所编写的脚本也可以用于负载测试。

 

性能参数

每个计算机系统都有4个传统的参数：

l 延迟

l 吞吐量

l 利用率

l 效率

优化系统性能就是要减少延迟、增加其他3个参数的值。尽管这个定义很直观，但优化本身并不直观，因为这些参数彼此之间可以互相消长，而且它们会随时间、服务内容种类已经许多其他环境改变而改变。另外，对某个机构的目标来说，有些性能参数比其他参数重要。

 

1 延迟和吞吐量

延迟：是指请求与开始看到结果直接的间隔时间。有人选择延迟定义为开始请求和完成该请求直接的时间。

延迟的单位是时间。

 

吞吐量：是指单位时间内能够处理的传输量。

计算吞吐量的简单方法：累加一段时间内的传输量，然后再将其除以这段的时间。但这样计算可能会产生正确的结果，也容易误导人，因为它忽略了在样本时间内传输速度的变化。最好是采用：每个采用点相除，然后再累加算平均值。

 

2 度量网络的延迟

注意这里考虑的是网络延迟，不是应用程序的延迟（应用程序的延迟是指运行在网络服务器上的应用程序本身从开始到返回结果需要花费的时间）。

 

因特网大部分延迟可能是路由器的存储和转发能力决定的。路由器接收一个进入的数据包，并将它放在一个缓冲区里，查看其报头信息，然后决定该数据包下一步将发往何处。即时已经决定发往何处，通常路由器仍然需要等待下一个时隙用户该数据包的发送，于是数据包的延迟在很大程度上取决于Web服务器和用户直接的路由跳数的数目。

也就是说，路由跳数的数目(hops)直接决定了网络的延迟。

那么利用traceroute功能就可以查到上文提到的hops，也可以使用mtr，mtr是结果和traceroute和ping的功能。

Hops越少约好。

Ping的延迟在50ms左右比较理想，超过100ms就不太理想了。

 

2.1 度量网络延迟和吞吐量

度量延迟和吞吐量最简单的方法是：弄清楚浏览器的高速缓存区的大小和从服务器获得一个特定页面所花的时间。可以使用lynx或者curl命令来获取相关数据。

比如：time lynx -source http://www.51.com/ > /dev/null，这种方法也可以认为是Web性能监控的stopwatch方法。

 

使用FTP

另一个度量网络吞吐量的方法是，利用FTP在本机和某个远程系统之间来回传输文件。但是使用FTP也有个不足，因为传输文件如果涉及到磁盘操作，那么这样做也是不准确的。

取消任何可能FTP传输引起的访问磁盘的请求。

必须利用大文件，因为每次小文件的创建都需要一个磁盘访问。

不过，可以利用某些版本ftp的将结果输出到/dev/null来达成结果。

ftp> get bigfile > /dev/null

 

其实用wget、curl等命令也是一样的，都是基于TCP的传输。但是不能清楚的区分网络性能和服务器性能。

 

以上也可以写成脚本来记录一段时间的运行情况，这样获得的结果会准确。

 

3 利用率

简单地说，利用率就是实际使用某组件的容量和该组件本身容量的百分比。数学表达式：

利用率 = 

为了充分利用所花的钱，都希望组件的利用率为100%，但是实际上并不必须如此。因为当利用率太高时就会出现很大的延迟。就经验而言，许多组件在利用率约为70%时性能最好。

perfmeter工具为监控系统利用率提供了一种很好的图形界面。

4 有效性

有效性 = （作为比较组件的一个基本方面是有用的，但在其他方面并没有多大用处，因为它仅仅是由其他两个性能参数相除得的结果）

一种更有用的有效性度量是计算单位开销获得的性能，这通常叫成本效率（cost efficiency）。

优化性能就是增加成本效率的艺术，即充分利用所花的每一分钱。实际上，因特网本身所具有的流行性就说明了这样一个事实。比如：email的延迟吞吐量比传统的邮递要快，成本低。

 

成本效率（cost efficiency）= 单位开销所得的性能

 

5 使用脚本监控Web性能

面对的庞大的Web数据，如果手动来监控Web性能显然是不可能的，所以这里势必促使我们使用脚本自动来实现，不然perl，python，php，shell等工具。

这里的监控是自动模拟用户登陆的行为，然后记录下各个操作点时间。

通过监控获取日志，然后对日志进行分析，这样就可以得出相关的报表。当然日志也可以保存在数据库里。

 

注意：过渡的监控对Web站点的运行同样有害！

 

 

 

6 关键性建议

l 不要太依赖基准，除非这些基准与你实际想做的密切相关。

l 不仅监控服务器的负载，而且监控实际的Web性能，并作记录。

l 不要进行过多的监控，否则你将成为制造问题的一份子。

需求的变化以及新技术的发展日新月异，所以你无法确切知道一两年后你到底需要什么。一种比较好的办法是：选择一些灵活性大的、能扩展的、有足够容量的的设备，将他们集成在一起（所以这里又涉及到一个可扩展、灵活性大的架构。按下不表以后再说），当需要修改数据或者选择新设备时，你能方便地增加容量和改变系统架构。建议你选择与其他制造商的产品“相处融洽”的组件，这种方法的好处在于随后能不断反馈给你关于性能和交互设备的可靠性方面的信息。

 

不要过于相信厂家的规范书和广告宣传，它们没有第一手经验或者来自朋友的信息可靠。更让人震惊的是，有些厂商会伪造相关标准和测试结果。所以在建立系统时，就应该预料到系统的性能情况，这样有助于检验、分析模型和现实之间的差距。

 

请记住：组件的额定值是产品供应商能鼓吹的最大值，最理想情况下产生的值，这些并非你在实际中所使用的值。而且很多产品在使用一年后就会出现莫名其妙的硬件问题。

 

必须注意的是：当在吞吐量很高的时候进行测试时，应该确保延迟在一定范围之内；同时还

要注意，当延迟确实升上去时到底有什么事情会发生。许多应用程序对延迟很敏感，他们不会等待太长时间。所以这里需要特别注意：吞吐量和延迟的关系，在测试的时候必须有这样的数学模型。