性能规范参考指标

用户满意度

参考Apdex( Application Performance Index)。

Apdex 标准从用户的角度出发,将对应用响应时间的表现,转为用户对于应用性能的可量化为范围为 0-1 的满意度评价。

Apdex 定义了应用响应时间的最优门槛为 T,另外根据应用响应时间结合 T 定义了三种不同的性能表现:

  • Satisfied(满意):应用响应时间低于或等于 T,比如 T 为 1.5s,则一个耗时 1s 的响应结果则可以认为是 satisfied 的。
  • Tolerating(可容忍):应用响应时间大于 T,但同时小于或等于 4T。假设应用设定的 T 值为 1s,则 4 * 1 = 4 秒极为应用响应时间的容忍上限。
  • Frustrated(烦躁期):应用响应时间大于 4T。

计算公式:
Satisfied Count 就是指定采样时间内响应时间满足 Satisfied 要求的应用响应次数;而 Tolerating Count 就是指定采样时间内响应时间满足 Tolerating 要求的应用响应次数;最后的 Total Samples 就是总的采样次数总数。从公式可以看出,应用的 Apdex 得分与采样持续时间无关,与目标响应时间 T 相关(在采用总数固定的情况下,T 通过影响 Satisfied Count以及 Tolerating Count的值间接影响最终的得分)

计算示例:假设应用期待的响应时间能够在 1000 ms 内,在 100 次采样中,有 50 次应用响应时间低于 1000 ms,30 次应用响应时间处于 1000 ms 到 4000 ms( 4 * 1000ms) 之间,剩下 20 次响应时间长于 4000 ms,那么,该应用在 T = 1000ms 的情况下的 Apdex 值为:(50+30/2)/100=0.65
建议:核心功能Apdex不低于0.9,边缘功能Apdex不低于0.8

响应时间

参考业内2-5-10原则

  • 当用户能够在2秒以内得到响应时,会感觉系统的响应很快;
  • 当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;
  • 当用户在5-10秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;
  • 而当用户在超过10秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求。 建议:核心功能响应时间2S以内,边缘功能响应时间5S以内

错误率

错误率指系统在负载情况下,失败请求的概率。错误率=(失败请求数/请求总数)*100%。
建议:核心功能错误率不超过千分之六,即小于0.6%,边缘功能错误率不超过千分之十,即小于1%

系统处理能力

系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。

单位:TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒

计算方法:Throughput = (number of requests) / (total time)
吞吐量-负载对应关系:
①上升阶段:吞吐量随着负载的增加而增加,吞吐量和负载成正比;
②平稳阶段:吞吐量随着负载的增加而保持稳定,无太大变化或波动;
③下降阶段:吞吐量随着负载的增加而下降,吞吐量和负载成反比;

a1面积越大,说明系统的性能能力越强,a2面积越大,说明系统稳定性越好,a3面积越大,说明系统的容错能力越好

软件指标

一级指标二级指标单位解释
GCGC频率次/秒java虚拟机垃圾部分回收频率
GC时长用于垃圾回收的时长
Thread错误请求次/秒错误请求数
request请求次/秒总request请求数
繁忙线程繁忙线程数
JDBCJDBC连接数
调用复杂度调用复杂度

建议:GC频率不能频繁,特别是FULL GC更不能频繁;当前正在运行的线程数不能超过设定的最大值;当前运行的JDBC连接数不能超过设定的最大值;调用复杂度10以下。

数据库指标

一级指标二级指标单位解释
SQL耗时微秒执行SQL耗时
命中率Key Buffer命中率%索引缓冲区命中率
Query Cache命中率%查询缓存命中率
Table Cache命中率%表缓存命中率

mysql Query Cache机制:QueryCache是根据SQL语句来cache的。一个SQL查询如果以select开头,那么MySQL服务器将尝试对其使用QC,若命中该缓存,会立刻返回结果,跳过了解析,优化和执行阶段。每个Cache都是以SQL文本作为key来存的。一个被频繁更新的表如果被应用了QC,可能会加重数据库的负担,涉及频繁更新的表的SQL语句加上SQL_NO_CACHE关键词来对其禁用CACHE,这样可以尽可能避免不必要的内存操作。

扩展性指标

指应用软件以群集方式部署,增加的硬件资源与增加的处理能力之间的关系。正常情况下扩展指标应该是线性或者接近线性。

可靠性指标

节点切换、故障恢复耗时1S内,并且无业务中断(失败请求)

硬件资源指标

序号指标解释标准
1CPU使用率指用户进程与系统进程消耗的CPU时间百分比长时间情况下,一般可接受上限不超过85%
2内存利用率内存利用率=(1-空闲内存/总内存大小)*100%一般至少有10%可用内存,内存使用率可接受上限为85%;
3磁盘I/O磁盘主要用于存取数据,对应的是写IO操作与读IO操作一般使用% Disk Time(磁盘用于读写操作所占用的时间百分比)度量磁盘读写性能
4网络带宽使用计数器Bytes Total/sec来度量,其表示为发送和接收字节的速率;判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较

系统按照最大容量的80%或标准压力(系统的预期日常压力)情况下运行,能够稳定运行的时间长短。

稳定性指标

TPS曲线稳定,没有大幅度的波动;其余各项指标正常。

备注

Minor GC ,Full GC 触发条件

Minor GC触发条件:当Eden区满时,触发Minor GC。

Full GC触发条件:

(1)调用System.gc时,系统建议执行Full GC,但是不必然执行

(2)老年代空间不足

(3)方法区空间不足

(4)通过Minor GC后进入老年代的平均大小大于老年代的可用内存

(5)由Eden区、From Space区向To Space区复制时,对象大小大于To Space可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小

转载于:https://www.cnblogs.com/aresxin/p/p35435.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库设计规范化的五个要求 数据库逻辑设计是优化关系数据库的核心。而数据库设计的规范化则是这个核心的核 心。一个规范化的逻辑数据库,可以为数据库管理员优化数据库和应用程序性能打下坚 实的基础。相反,若逻辑数据库设计不规范,则会损害整个数据库,包括应用程序的性 能。   通常情况下,可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥 有大量的窄表,二是宽表的数量是否足够的少。若符合这两个条件,则可以说明这个数 据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计 规范化的要求,一般来说,需要符合以下五个要求。 要求一:表中应该避免可为空的列   虽然表中允许空列,但是,空字段是一种比较特殊的数据类型。数据库在处理的时 候,需要进行特殊的处理。如此的话,就会增加数据库处理记录的复杂性。当表中有比 较多的空字段时,在同等条件下,数据库处理的性能会降低许多。   所以,虽然在数据库表设计的时候,允许表中具有空字段,但是,我们应该尽量避 免。若确实需要的话,我们可以通过一些折中的方式,来处理这些空字段,让其对数据 库性能的影响降低到最少。 一是通过设置默认值的形式,来避免空字段的产生。 二是若一张表中,允许为空的列比较多,接近表全部列数的三分之一。而且,这些列 在大部分情况下,都是可有可无的。若数据库管理员遇到这种情况,建议另外建立一张 副表,以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个 独立的表中使得主表的设计更为简单,同时也能够满足存储空值信息的需要。 要求二:表不应该有重复的值或者列   如进销存管理中,还需要对客户的联系人进行管理。而一个客户的联系人可能有多 个,为了解决这个问题,有多种实现方式。若设计不合理的话在,则会导致重复的值或 者列。我们可以这么设计,把客户信息、联系人都放入同一张表中。为了解决多个联系 人的问题,可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等 。若还有第三联系人、第四联系人等等,则往往还需要加入更多的字段。   可是这么设计的话,会产生一系列的问题。如客户的采购员流动性比较大,在一年 内换了六个采购员。直接修改又不利于追踪。   所以,在数据库设计的时候要尽量避免这种重复的值或者列的产生。建议,若数据 库管理员遇到这种情况,可以改变一下策略。如把客户联系人另外设置一张表。然后通 过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说,尽量将重复的值放 置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。 要求三:表中记录应该有一个唯一的标识符。   在数据库表设计的时候,数据库管理员应该养成一个好习惯,用一个ID号来唯一的 标识行记录,而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID 列,任何两个记录都不可以共享同一个ID值。另外,这个ID值最好有数据库来进行自动 管理,而不要把这个任务给前台应用程序。否则的话,很容易产生ID值不统一的情况。  另外,在数据库设计的时候,最好还能够加入行号。ID号是用户不能够维护的。但是 ,行号用户就可以维护。这是在实际应用程序设计中对ID列的一个有效补充。 要求四:数据库对象要有统一的前缀名。   一个比较复杂的应用系统,其对应的数据库表往往以千计。若让数据库管理员看到 对象名就了解这个数据库对象所起的作用,恐怕会比较困难。而且在数据库对象引用的 时候,数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。   建议:在开发数据库之前,最好能够花一定的时间,去制定一个数据库对象的前缀 命名规范。最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。需要注 意的是,这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识,并且 严格按照这个命名规范来定义对象名。   其次,表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀,而函数则可 以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候,都能够在最 短的时间内找到自己所需要的对象。 要求五:尽量只存储单一实体类型的数据。   实体类型跟数据类型不是一回事,要注意区分。如现在有一个图书馆里系统,有图 书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中 也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话,会给后 续的维护带来不少的麻烦。   如当后续有图书出版时,则需要为每次出版的图书增加作者信息,这无疑会增加额 外的存储空间,也会增加记录的长度。而且若作者的情况有所改变,如住址改变了以后 ,则还需要去更改每本书的记录。同时,若这个作者的图书从数据库中全部删除之后, 这个作者的信息也就荡然无存了。很明显,这不符合数据库设

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值