架构高性能网站秘笈(一)——了解衡量网站性能的指标

简介: 服务器如何发送数据?服务器程序将需要发送的数据写入该程序的内存空间中;服务器程序通过操作系统的接口向内核发出系统调用;系统内核将用户态内存空间中的数据复制到内核缓冲区中去,然后通知网卡过来取;此后CPU转而做其他处理;网卡到CPU指定的内核缓冲区中将数据复制到网卡缓冲区中;网卡将字节转换成二进制位,再以电信号的形式输出至网络。

服务器如何发送数据?

  1. 服务器程序将需要发送的数据写入该程序的内存空间中;
  2. 服务器程序通过操作系统的接口向内核发出系统调用;
  3. 系统内核将用户态内存空间中的数据复制到内核缓冲区中去,然后通知网卡过来取;此后CPU转而做其他处理;
  4. 网卡到CPU指定的内核缓冲区中将数据复制到网卡缓冲区中;
  5. 网卡将字节转换成二进制位,再以电信号的形式输出至网络。

注意:数据在计算机内部的复制是按照总线的宽度来复制的。比如在32位的操作系统中,数据每次都复制32位。 
总线就像是一条32/64车道的马路,数据在计算机中是以0/1的形式存储,每次复制每条车道只能走一个0/1,因此每次只能同时复制32个0/1. 

数据在网线中的速度

网络传输介质有光缆和铜缆,在光缆中电信号的传输速度为2.3x10^8m/s,在铜缆中传输速度为2.0x10^8m/s。 
光的传播速度为3.0x10^8m/s,但由于光缆采用反射机制传播,并不是直射,因此电信号实际走的路程要比直线长很多,因此在光缆中的传播速度只有2.0x10^8m/s。 

什么是带宽?

带宽的定义

带宽的定义:数据的发送速率。

带宽的单位

100Mbps = 100M bit per second 
平时所说的100M带宽指的是100M比特每秒, 
100Mbps = 12.5MBps

注意:我们平时所说的“100M”指的是100MB,而带宽的单位是Mb,而1MB = 8Mb。因此,运营商所说的“百兆宽带”其实是“12.5兆宽带”,呵呵。 

什么影响了数据发送速度(带宽)?

  1. 数据的发送速度由接收方的接收速度决定。在数据链路层中,为了确保数据在接收过程中不发生丢失,因此接收方要告诉发送方目前发送速度是否合理。若接收方来不及收,就会告诉发送方,让它慢点发。因此,数据的发送速度(即带宽)由接收方的接收速度决定。
  2. 与传播介质的并行度有关。传输介质可以看成是多车道马路,数据由0/1组成,每股车道每次只能容纳一个0/1。因此,如果马路的车道增多,那么每次发送的0/1也就增多,从而提高了发送速度(即带宽). 

运营商为什么要限制带宽?

我们的服务器会通过一个交换机连入互联网,互联网由无数个路由器和主机构成,路由器负责数据包的存储转发,将数据包根据目的地址途径一个个路由器,最终投递到目的主机中。

由于一个交换机往往有多个服务器接入,服务器们都会将需要发送的数据首先发给交换机,再由交换机发给路由器,这些数据先存储在路由器的缓存中,然后路由器根据先后顺序逐个转发。所以,如果服务器发送数据的速度过快,路由器缓存满了,那接下来的数据就会丢失,因此需要限制服务器向路由器发送数据的速度,即限制服务器的带宽。而这个限制由接入服务器的交换机完成。通过上文可知,交换机只要控制接收速度,就能限制服务器的发送速度。 

什么是共享带宽?什么是独享带宽?

1.独享带宽 
如果一个路由器的出口带宽为100Mbps,并且同一个广播域内有10台主机,交换机只要将每台主机的最大出口带宽限制为10Mbps,那么不管在任何情况下每台主机的最大出口带宽为10Mbps。这就是独享带宽。独享带宽不会受到同一个广播域内其他主机的影响,任何时候最大出口带宽均为10Mbps。

2.共享带宽 
假设一个路由器的出口带宽仍为100Mbps,但运营商为了挣更多钱,使同一个广播域内有多于10个主机接入,那么每台主机的平均最大带宽就小于10Mbps,此时即使交换机仍然将每台主机的最大出口带宽限制为10Mbps,但当主机都有较大的网络通信时,就无法保证每台主机都有10Mbps的最大带宽,此时就会相互竞争带宽。

综上所述,独享10M带宽能保证服务器的最大出口带宽在任何情况下都为10Mbps,不会受到同一广播域内的其他主机影响;而共享10M带宽只能保证在同一广播域内的其他主机通信空闲时,才能达到最大10Mbps的出口带宽。 

什么是响应时间?

响应时间是指从数据包的第一个0/1离开服务器开始,到最后一个0/1被客户端接收为止的这段时间。

响应时间 = 发送时间+传输时间+处理时间

  • 发送时间:从发送数据包的第一个0/1开始,到发完最后一个0/1为止的这段时间。 
    发送时间=数据包比特数/带宽
  • 传输时间:数据在通信线路中的传输时间。 
    传输时间=传输距离/传输速度 
    (传输速度近似为2x10^8m/s)
  • 处理时间:数据在各个路由器中存储转发的时间。 
    处理时间比较难以计算。

响应时间=(数据包比特数/带宽)+(传输距离/传输速度)+处理时间

下载速度=数据的字节数/响应时间 

什么是吞吐率?

吞吐率:服务器单位时间内处理请求的个数。 
单位:reqs/s

吞吐率用来衡量服务器处理请求的能力。

当请求非常少的时候吞吐率并不高,因为此时服务器的性能还没有体现出来。那么随着请求的不断增多,吞吐率会随之上升,但当并发请求数上升到某一个临界点时,吞吐率不升反降。那个临界点就是服务器吞吐率的最大值,也叫最大吞吐率。

若我们的网站有促销活动前,可以通过上述方法来估计服务器的最大吞吐率,从而能判断服务器能否顶住促销带来的压力。 

什么是并发数?什么是并发用户数?

要搞清楚并发数和并发用户数的区别,首先需要了解HTTP协议。

HTTP协议是一种应用层协议,它本身是无连接的,也就是客户端与服务器每完成一次数据交互就需要断开连接,下次通信时重新建立连接。但是HTTP1.1中有一个keep-alive字段,它使得通信双方在完成一次通信后仍然保持一定时长的连接。若该时间内客户端又想与服务器通信,那么无需再创建新的连接,只需重用刚才的连接即可,这样能提高通信的效率,减少额外的开销。

  • 并发数:客户端向服务器请求的次数。不论是否延用已创建的连接,只要客户端向服务器提出请求,就算一个并发数。
  • 并发用户数:创建TCP连接的个数。如果一个浏览器延用了已创建的连接向服务器发送了10次请求,那么只算一个并发用户数。

注意:现在的浏览器支持多线程,可以同时与服务器建立多个TCP连接,因此一个用户可能会导致多个并发用户数。所以“并发用户数”和“用户数”不能完全画等号,这点需要注意! 

平均请求等待时间 和 服务器平均请求处理时间

平均请求等待时间:用户从点击一个按钮,到新的页面加载完毕所需的时间。

服务器平均请求处理时间:服务器从等待队列中取出一个请求开始,到处理完该请求所需的时间。

综上所述:平均请求处理时间是站在用户角度,是用来衡量用户体验的好坏的指标。 
而服务器平均请求处理时间是衡量服务器性能好坏的指标,其实就是吞吐率的倒数。

注意:平均请求等待时间 和 服务器平均请求处理时间不成正比关系! 
平均请求等待时间=请求传输时间+请求等待时间+请求处理时间 
服务器平均请求处理时间=请求处理时间 
由此可知,在请求数很少的情况下,浏览器发来的请求无需等待,直接被服务器处理,那么请求等待时间和服务器请求处理时间成正比关系;但在请求异常多的时候,请求到来速度远远大于服务器处理请求的速度,那么很多请求将会在等待队列中挤压,此时即使服务器处理请求的能力很强(即服务器平均请求处理时间很短),但用户的等待时间依然很长,此时用户等待时间与服务器请求处理时间不成正比。 

使用Apache Bench进行压力测试

我们使用Apache服务器的Apache Bench(简称ab)对网站进行压力测试。ab简单易用,关键可以直接在服务器本地发起测试,这样我们可以获取不包括传输时间的服务器处理时间。通过服务器处理时间就可以知道服务器的性能。

1. 压力测试命令

ab -n100 -c10 http://www.acmcoder.com/index.php
  • 1

2. 测试结果解析

Server Software:        openresty #服务器软件
Server Hostname:        www.acmcoder.com #测试的网址
Server Port:            80 #访问的端口号

Document Path:          /index.php #测试的网页
Document Length:        162 bytes #HTTP响应信息的正文长度

Concurrency Level:      10 #并发用户数
Time taken for tests:   1.497209 seconds #测试所花费的时间
Complete requests:      100 #总请求数
Failed requests:        0 #失败的请求数(响应码非2xx的请求由Non-2xx responses记录)
Write errors:           0 
Non-2xx responses:      100 #HTTP响应头中状态码非2xx的响应个数
Total transferred:      32400 bytes #总的响应数据长度,包括HTTP响应的头和正文数据,但不包括请求数据。
HTML transferred:       16200 bytes #HTTP响应中正文数据的长度。
Requests per second:    66.79 [#/sec] (mean) #吞吐率
Time per request:       149.721 [ms] (mean) #用户平均请求等待时间
Time per request:       14.972 [ms] (mean, across all concurrent requests) #服务器平均请求处理时间
Transfer rate:          20.71 [Kbytes/sec] received #服务器的数据传输速度(在极限情况下该数据即为服务器出口带宽)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       40   46   4.8     46      58
Processing:    41   46   5.0     46      58
Waiting:       40   46   4.9     45      58
Total:         81   92   9.7     92     116

Percentage of the requests served within a certain time (ms)
  50%     92 #50%的请求在92毫秒内完成
  66%     98
  75%     99
  80%    101
  90%    107
  95%    114
  98%    115
  99%    116
 100%    116 (longest request)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37


如何选择网站的被测URL?

一个网站的URL可能有很多,每个URL对应的处理也不尽相同,某一个URL的测试结果并不具有代表性。因此,我们需要选择一系列有代表性的URL,将测试结果的加权平均数作为网站的综合性能。


相关文章
|
1月前
|
消息中间件 Java 微服务
构建高性能微服务架构:Java后端实践
【4月更文挑战第8天】 在当今互联网应用的快速迭代与高并发挑战下,微服务架构以其灵活性和扩展性成为众多企业技术选型的宠儿。本文将深入探讨在Java后端开发中,如何构建一个高性能的微服务系统,涵盖从基础架构设计、关键技术选型到性能优化策略的全方位分析。我们将透过实际案例,剖析微服务实践中的最佳模式与常见陷阱,为后端开发人员提供一份实操指南。
|
13天前
|
监控 持续交付 数据库
构建高性能微服务架构:后端开发的新范式
【4月更文挑战第27天】 在当今快速演进的技术景观中,微服务架构已成为软件开发的一项关键策略。它允许开发团队以模块化的方式构建、部署和维护应用程序,从而提高了可伸缩性和灵活性。本文将深入探讨如何构建一个高性能的微服务架构,涵盖从选择合适的技术栈到优化服务的各个方面。通过实际案例和最佳实践的分享,我们将展示如何在保证系统稳定性的同时,提升应用的性能和响应速度。
|
2月前
|
人工智能 运维 监控
构建高性能微服务架构:现代后端开发的挑战与策略构建高效自动化运维系统的关键策略
【2月更文挑战第30天】 随着企业应用的复杂性增加,传统的单体应用架构已经难以满足快速迭代和高可用性的需求。微服务架构作为解决方案,以其服务的细粒度、独立性和弹性而受到青睐。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、常用的技术栈选择以及性能优化的最佳实践。我们将分析微服务在处理分布式事务、数据一致性以及服务发现等方面的挑战,并提出相应的解决策略。通过实例分析和案例研究,我们的目标是为后端开发人员提供一套实用的指南,帮助他们构建出既能快速响应市场变化,又能保持高效率和稳定性的微服务系统。 【2月更文挑战第30天】随着信息技术的飞速发展,企业对于信息系统的稳定性和效率要求
|
4天前
|
缓存 监控 数据库
构建高性能微服务架构:后端开发的终极指南
【5月更文挑战第6天】 在现代软件开发的浪潮中,微服务架构以其灵活性、可扩展性和容错性引领着技术潮流。本文深入探索了构建高性能微服务架构的关键要素,从服务划分原则到通信机制,再到持续集成和部署策略。我们将透过实战案例,揭示如何优化数据库设计、缓存策略及服务监控,以确保系统的稳定性和高效运行。文中不仅分享了最佳实践,还讨论了常见的陷阱与解决之道,为后端开发者提供了一条清晰、可行的技术路径。
|
5天前
|
缓存 NoSQL Java
构建高性能微服务架构:Java后端的实践之路
【5月更文挑战第5天】在当今快速迭代和高并发需求的软件开发领域,微服务架构因其灵活性、可扩展性而受到青睐。本文将深入探讨如何在Java后端环境中构建一个高性能的微服务系统,涵盖关键的设计原则、常用的框架选择以及性能优化技巧。我们将重点讨论如何通过合理的服务划分、高效的数据存储策略、智能的缓存机制以及有效的负载均衡技术来提升整体系统的响应速度和处理能力。
|
11天前
|
API 持续交付 开发者
构建高性能微服务架构:挑战与解决方案
【4月更文挑战第29天】 随着现代软件开发的复杂性日益增加,微服务架构成为众多企业和开发者的首选。它通过将大型应用程序拆分为一系列小型、自治的服务来提供灵活性和可扩展性。然而,随之而来的是一系列的挑战,包括服务间通信、数据一致性、安全性和性能优化等。本文将深入探讨在构建高性能微服务架构过程中可能遇到的挑战,并提供针对性的解决方案,以帮助开发者克服这些难题,实现更加健壮和高效的系统。
|
13天前
|
监控 持续交付 数据库
构建高性能微服务架构:后端开发的新范式
【4月更文挑战第27天】 随着现代业务需求的多样化和快速迭代,传统的单体应用架构逐渐显得笨重且难以适应。本文旨在探讨一种新的后端开发范式——微服务架构,它以其灵活性、可扩展性和技术多样性成为当前软件开发的热点。我们将深入分析微服务的核心概念、实施策略以及在性能优化方面的实践技巧。通过本文,读者将获得如何构建一个既高效又稳定的微服务系统的知识,同时了解持续集成与容器化技术如何助力微服务的部署与管理。
|
15天前
|
JSON API 数据库
后端架构设计与优化:打造高性能应用后端
后端架构设计与优化:打造高性能应用后端
25 2
|
16天前
|
消息中间件 监控 Serverless
构建高性能微服务架构:后端开发的新趋势
【4月更文挑战第24天】 在现代软件开发的浪潮中,微服务架构已经成为了企业追求敏捷、可扩展和容错性的关键解决方案。本文将深入剖析如何构建一个高性能的微服务系统,涵盖关键的设计原则、技术选型以及性能优化策略。通过实例驱动的方法,我们将探讨如何利用容器化、服务网格、API 网关等技术手段,以及无服务器架构(Serverless)的兴起,来构建一个既灵活又高效的后端系统。
|
16天前
|
负载均衡 监控 开发者
构建高性能微服务架构:后端开发的终极指南
【4月更文挑战第24天】 在当今快速迭代和高并发的互联网环境中,构建一个高性能、可扩展且易于维护的后端系统显得至关重要。微服务架构作为解决复杂系统问题的有效方法,已经成为众多企业的首选架构模式。本文将深入探讨如何利用最新的后端技术和实践来构建高性能的微服务架构,包括服务拆分、容器化部署、服务发现与注册、负载均衡策略以及分布式事务管理等关键技术点,旨在为开发者提供一套全面的技术解决方案和实施建议。