网站cdn自己做,互动网站策划,零基础学it哪个专业好,商业空间设计调研https://blog.csdn.net/JGMa_TiMo/article/details/118481054 响应时间(RT) 响应时间是指系统对请求作出响应的时间。直观上看#xff0c;这个指标与人对软件性能的主观感受是非常一致的#xff0c;因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许…
https://blog.csdn.net/JGMa_TiMo/article/details/118481054 响应时间(RT) 响应时间是指系统对请求作出响应的时间。直观上看这个指标与人对软件性能的主观感受是非常一致的因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能而不同功能的处理逻辑也千差万别因而不同功能的响应时间也不尽相同甚至同一功能在不同输入数据的情况下响应时间也不相同。所以在讨论一个系统的响应时间时人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 对于单机的没有并发操作的应用系统而言人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是响应时间的绝对值并不能直接反映软件的性能的高低软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说响应时间小于100毫秒应该是不错的响应时间在1秒左右可能属于勉强可以接受如果响应时间达到3秒就完全难以接受了。而对于编译系统来说完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间但这些响应时间对于用户来说都是可以接受的。 吞吐量(Throughput) 吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言吞吐量与响应时间成严格的反比关系实际上此时吞吐量就是响应时间的倒数。前面已经说过对于单用户的系统响应时间或者系统响应时间和应用延迟时间可以很好地度量系统的性能但对于并发系统通常需要用吞吐量作为性能指标。 对于一个多用户的系统如果只有一个用户使用时系统的平均响应时间是t当有你n个用户使用时每个用户看到的响应时间通常并不是n×t而往往比n×t小很多当然在某些特殊情况下也可能比n×t大甚至大很多。这是因为处理每个请求需要用到很多资源由于每个请求的处理过程中有许多不走难以并发执行这导致在具体的一个时间点所占资源往往并不多。也就是说在处理单个请求时在每个时间点都可能有许多资源被闲置当处理多个请求时如果资源配置合理每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上不同系统的平均响应时间随用户数增加而增长的速度也不大相同这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言吞吐量是一个比较通用的指标两个具有不同用户数和用户使用模式的系统如果其最大吞吐量基本一致则可以判断两个系统的处理能力基本一致。 并发用户数 并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比并发用户数是一个更直观但也更笼统的性能指标。实际上并发用户数是一个非常不准确的指标因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例假设用户只有注册后才能使用但注册用户并不是每时每刻都在使用该网站因此具体一个时刻只有部分注册用户同时在线在线用户就在浏览网站时会花很多时间阅读网站上的信息因而具体一个时刻只有部分在线用户同时向系统发出请求。这样对于网站系统我们会有三个关于用户数的统计数字注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言以在线用户作为性能指标更直观些而以同时发请求用户数作为性能指标更准确些。 QPS每秒查询率(Query Per Second) 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准在因特网上作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec即每秒的响应请求数也即是最大吞吐能力。 看来是类似于TPS只是应用于特定场景的吞吐量 关键指标响应时间、QPS每秒查询数、TPS每秒处理的事务数、成功率。根据不同的业务场景平衡各个指标之间的关系。 响应时间 当用户在2秒内得到响应会感觉系统的响应很快 当用户在2~5秒内得到响应会感觉系统的响应速度很慢可以接受 当用户超过8秒仍不能得到响应会感觉系统很糟糕此时会选择离开站点或者发起二次请求。 有同学可能会问例如200QPS能支持多少用户访问大概是以下公式推算 500万人大概200qps。 公式( 总PV数 * 80% ) / ( 每天秒数 * 20% ) 峰值时间每秒请求数(QPS) 。
SLA服务登记协议服务提供者对服务消费者的正式承诺是衡量服务能力等级的关键项。
TPS每秒处理的事务数从客户端发起请求开始计时等收到服务器端响应结果后结束计时在计算这个时间段内总共完成的事务个数。一个事务指的是客户端发起一个请求并且等到请求返回之后的整个过程。 QPS每秒的查询请求数表示服务器端每秒能够响应的查询次数。一个TPS中可能会包括多个QPS。 RT响应时间表示客户端发出请求到服务端返回的时间间隔一般表示平均响应时间。 并发数指的是系统同时能处理的请求数量。如果QPS1000表示每秒钟客户端会发起1000个请求到服务端而如果一个请求的处理耗时是3s那么意味着总的并发1000*33000也就是服务端会同时有3000个并发。
指标的计算 假设在一个小时内有200W用户访问系统平均每个用户请求的耗时是3秒。 QPS2000000/(6060)556 并发数55631668 随着RT的值越大并发数越多意味着服务端占用的连接数越多会消耗内存资源和CPU资源等。在实际业务中RT的值越小越好应该缩小RT的值。
2/8法则推算1000W用户的访问量 1000w用户每天访问的用户占20%也就是每天有200w用户来访问。假设平均每个用户过来点击5次总共的pv1亿。一天24小时根据2/8法则每天8000w80%用户活跃的时间点集中在24*0.25小时内。此时的 QPS 45008000w/5小时平均每秒查询数。在这5个小时中请求并非非常平均可能会存在大量的用户集中访问因此一般情况下访问峰值是平均访问请求的3~4倍左右此时的QPS大约QPS18000。
服务器压力估计 TCP连接对于系统资源最大的开销就是内存。 因为tcp连接归根结底需要双方接收和发送数据那么就需要一个读缓冲区和写缓冲区这两个buffer在linux下最小为4096字节可通过cat /proc/sys/net/ipv4/tcp_rmem和cat /proc/sys/net/ipv4/tcp_wmem来查看。 所以一个tcp连接最小占用内存为40964096 8k那么对于一个8G内存的机器在不考虑其他限制下最多支持的并发量为810241024/8 约等于100万。此数字为纯理论上限数值在实际中由于linux kernel对一些资源的限制加上程序的业务处理所以8G内存是很难达到100万连接的当然我们也可以通过增加内存的方式增加并发量。
如何降低RT的值 请求执行过程中会做的事情查询数据库、访问磁盘数据、进行内存运算、调用远程服务。 每一步操作都会消耗一定量的时间当前客户端的请求只有等到这些操作都完成之后才能返回因此降低RT可以通过优化业务处理逻辑。
1 数据库优化 当18000个请求进入到服务端并且被接收后开始执行业务逻辑处理那么必然会查询数据库。每个请求至少都有一次查询数据库的操作多的需要查询3~5次以上我们假设按照3次来计算那么每秒会对数据库形成54000个请求假设一台数据库服务器每秒支撑10000个请求影响数据库的请求数量有很多因素比如数据库表的数据量、数据库服务器本身的系统性能、查询语句的复杂度那么需要6台数据库服务器才能支撑每秒10000个请求。 如果数据库服务器的并发连接请求量比较大建议调高此值以增加并行连接数量当然这建立在机器能支撑的情况下因为如果连接数越多介于MySQL会为每个连接提供连接缓冲区就会开销越多的内存所以要适当调整该值不能盲目提高设值。 数据表数据量过大比如达到几千万甚至上亿这种情况下sql的优化已经毫无意义了因为这么大的数据量查询必然会涉及到运算。 可以缓存来解决读请求并发过高的问题一般来说对于数据库的读写请求也都遵循2/8法则在每秒54000个请求中大概有43200左右是读请求这些读请求中基本上90%都是可以通过缓存来解决。 分库分表减少单表数据量单表数据量少了那么查询性能就自然得到了有效的提升•读写分离避免事务操作对查询操作带来的性能影响。 写操作本身耗费资源数据库写操作为IO写入写入过程中通常会涉及唯一性校验、建索引、索引排序等操作对资源消耗比较大。一次写操作的响应时间往往是读操作的几倍甚至几十倍。 锁争用写操作很多时候需要加锁包括表级锁、行级锁等这类锁都是排他锁一个会话占据排它锁之后其他会话是不能读取数据的这会会极大影响数据读取性能。所以MYSQL部署往往会采用读写分离方式主库用来写入数据及部分时效性要求很高的读操作从库用来承接大部分读操作这样数据库整体性能能够得到大幅提升。 为什么数据放入redis缓存中能提升性能 1redis存储的是k-v数据时间复杂度是0(1)MySQL存储引擎的底层实现是B树时间复杂度是O(logn)。 2Mysql数据存储是存储在表中查找数据时要先对表进行全局扫描或根据索引查找这涉及到磁盘IO磁盘查找如果是单点查找可能会快点但是顺序查找就比较慢。而redis不用这么麻烦本身就是存储在内存中会根据数据在内存的位置直接取出。 3Redis是单线程的多路复用IO单线程避免了线程上下文切换的开销而多路复用IO避免了IO等待的开销在多核处理器下提高处理器的使用效率可以对数据进行分区然后每个处理器处理不同的数据。 2 磁盘数据访问优化 对磁盘的访问主要是读和写操作优化方案如下 1磁盘的页缓存借助缓存IO充分利用系统缓存降低实际IO的次数。 2顺序读写可以用追加写代替随机写减少寻址开销加快IO写的速度。 3SSD代替HDD固态硬盘的IO效率远远高于机械硬盘。 4在需要频繁读写同一块磁盘空间时可以用mmap内存映射代替读写减少内存的拷贝次数。 5在需要同步写的场景下尽量将写请求合并而不是让每个请求都同步写入磁盘可以用fsync。
3 合理利用内存 充分利用内存缓存把一些经常访问的数据和对象保存在内存中这样可以避免重复加载或者避免数据库访问带来的性能损耗。比如利用redis缓存热点数据。
4 调用远程服务 远程服务调用的影响IO性能因素 远程调用等待返回结果的阻塞、异步通信、网络通信的耗时、内网通信、增加网络带宽、远程服务通信的稳定性。
5 异步化架构 微服务中的逻辑复杂处理时间长的情况在高并发下导致服务线程消耗尽不能创建线程处理请求。可以考虑在架构上做调整先返回结果给客户端让用户可以继续使用客户端的其他操作再把服务端的复杂逻辑处理模块做异步化处理。异步化处理适用于客户端对处理结果不敏感不要求实时的情况比如群发邮件、群发消息等。 ———————————————— 版权声明本文为CSDN博主「BUG记录机」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/JGMa_TiMo/article/details/118481054
