当前位置:首页>办公设备>打印机>

打印机端口为灰色不能删除怎么办(删除打印机端口删不掉)

打印机端口为灰色不能删除怎么办(删除打印机端口删不掉)

更新时间:2022-03-07 15:55:42

编辑导语:一件产品的完成,最重要的一环便是它的性能,好产品的性能必定是被人们所需要的。这篇文章详细阐述了产品性能需求的重要性,推荐想要了解性能要求的童鞋阅读。

我刚工作时,和政府部门做了个产品,功能就是个表单录入,录入完保存到系统。拿去给用户演示,一切很完美。

但是当开始试运行时,出现了问题——单据录入完成后,保存无反应。

后来一看是用户在每次会同时录入很多条内容,在保存100条数据要30s才能保存成功。500条数据直接保存失败。

当然,这是我的问题,忽略了对性能的要求。

性能的重要性不必细说,有些数据表明:近80%的用户反馈应用响应时间慢、点击没反应等性能问题。

一般在公司里会有专门的测试人员对系统进行性能测试,而对于性能的标准,具体性能指标多少合适,测试同学是不清楚的。

这个时候就需要产品狗们提出性能要求,给测试同学作参考。

接下来我们说说性能需求咋提以及性能指标。

文章较长,建议收藏吃灰~

一、性能需求什么时候提

性能需求属于非功能需求,一般在需求文档内需要有单独模块对性能做说明。

在写需求文档的时候就可以把性能需求一起规定好,在需求评审时也要评审下性能需求,让各方达成一致。

研发同学在做技术设计时考虑进来,避免在项目后期,出现重大性能问题。

测试同学在准备测试用例时,把性能也提前规划进来,提前准备好测试方案。

另外性能测试也会占用一定的项目时间,需要在制定项目计划时,把性能测试的时间也纳入计划中。

二、性能需求怎么提

性能需求是指对系统性能进行规范化描述,提出明确、合理的性能指标要求。

主要分为2个方面:

1.系统整体性能需求

主要指标包括

  • 在线用户数数量:如支持在线用户数200w
  • 平稳运行时间:如7×24h
  • 平均响应时间:如页面打开时间低于2s。(对于一些主要页面可以在做单独性能要求)
  • CPU:CPU使用率<75%

2.不同功能/接口性能需求

由于不同功能、不同接口的使用频率、重要程度不同,我们可以对不同功能、不同接口单独提出性能需求。

可以从下边几个标准来确定需要单独明确的功能/接口

  • 高频:系统中高频率使用的功能,高频调用的接口,像刷动态
  • 关键:系统中不能出现问题的功能,像登录、注册、支付
  • 特色:系统中的亮点功能,产品的卖点,比如处方合理性审核系统、风险监控系统,还有像交友的在线匹配功能。
  • 涉及大量数据:比如说报表查询。

举个“登录”功能的例子:

并发用户数500,响应时间2s,TPS到500/s,CPU不得超过75%。

下边我们详细说说性能指标以及性能指标的标准

三、常见的性能指标有哪些

主要有响应时间、并发数、吞吐量、CPU等,对于App需要关注FPS、启动时间、耗电量等。

我们一个个看看:

1. 响应时间——最直观的表现

“系统应该让用户知道发生了什么,在适当的时间内做出适当的反馈。”尼尔森可用性十原则——状态可见性

在尼尔森可用性十原则中的“状态可见性原则”提到的“适当的时间”就可以理解为响应时间。

站在用户角度描述就是点击一下按钮,系统在页面上给出反馈的时间。这个反馈时间是用户最能直观感受到的,也是对用户体验影响最大的地方。

当响应时间>5秒后,74%的PC端用户、50%以上的App用户会选择放弃操作,30%的用户会选择卸载应用,33%以上的用户会转身使用竞品。

吓人不?

我们接着看下响应时间的定义:提交请求和返回该请求的响应之间使用的时间。主要由网络传输时间和业务处理、数据处理时间组成。

而对于产品来说,需要关注的是页面响应时间,就算接口处理完成,数据传到客户端上了,在前端也需要解析出来,也会消耗一定时间。

响应时间多长才能满足要求呢?

之前有个2-5-10原则,而现在随着技术、硬件的更新换代,响应时间也有了1-3-5标准。

即1s内用户完全可以接受,3s内用户觉得还可以,5s用户就会开始焦躁不安。

当然这只是个通用标准,不是个固定标准。我们在提出需求时,可以结合业务重要性、数据量大小、使用频次来做综合考虑。

举个例子:导出excel报表。对于很多B端产品,这是个刚需、高频的功能。

我们可以这样提出性能要求:

  • 1万条数据,导出完成用时3s。
  • 3万条数据,导出完成用时5s。
  • 10万条数据,导出完成用时8s。

我从网上找到一些响应时间参考指标,大家可以看下:

  • 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。
  • 金融企业:1秒以下为佳,部分复杂业务3秒以下。
  • 保险企业:3秒以下为佳。
  • 制造业:5秒以下为佳。

2. 并发用户数——笼统也直观的指标

并发用户数的定义是每秒同时向服务器提交请求的用户总数量。

关于并发用户数有2个理解:

  1. 多个用户同一时间做不同操作,比如多个用户有发动态的,有刷动态的。
  2. 多个用户同一时间做同一个操作,比如多个用户一起发动态。

对于这2个理解,在性能需求上可以分开提,比如:

  • 系统支持并发用户数500
  • 发布动态:支持300人并发发布动态。

有几种并发用户数评估方法,大家可以看下:

1)公式1:

n:平均每天的访问用户数。App可以直接用日活代替。

L:一天内用户从登录到退出的平均时间,可以理解为平均用户使用时长。

T:考察时间长度,一天内多长时间有用户在使用系统。

举个例子:

App日活是10w,用户平均使用时长是10min,用户每天活跃时间大约是从早上10点到晚上10点。

公式里的n=10w,L=10min,T=12h

C=(10w×10min)/12h,时间单位统一成秒

C=(10w×10×60)/(12×3600)≈1388人/秒

峰值C’=1388×3×根号1388≈1500人/秒

提需求时可以以峰值并发用户数为准

2)公式2:

C=(用户总量/统计时间)*影响因子

影响因子一般为3

比如App的每天晚上8点-10点用户最活跃,且活跃用户有8w。

8w/2h×3≈33人/秒

3)公式3:

根据80~20原则:80%的请求在20%的时间内产生。然后结合PV一起算(注意不是UV,因为一个用UV产生多个PV)

比如1天的PV有100w

先算80%的PV:100w×80%=80w

20%的时间:24h×20%=4.8,换算出秒,就是4.8×3600=17280秒

并发数就是:80w/17280=46人/秒

如果是B端私有化部署的产品,一般使用人数比较固定,我们可以从企业人员数量做评估:用户数量×比例,比例可以视具体情况而定,一般取8%-20%。

当然这些都是评估方法,得出的具体数据量只是做个参考。

3. 吞吐量——衡量系统处理能力的重要指标。

吞吐量是指单位时间内系统能处理的请求数量,体现着系统处理请求的能力。

吞吐量的量化指标有:TPS(每秒事务数)、QPS(每秒查询数)

TPS:是指事务数/秒。一个事务是指服务器发送请求,服务器做出反应的过程。

整体过程就是:用户做出操作>>请求服务器>>服务器处理>>服务器处理完成返回到用户。

每秒能完成多少个流程就是多少个TPS

简单理解:就是登录一次算一个事务,每秒能完成2个登录事务,就是2个TPS。

QPS:是指每秒查询率。指一台服务器每秒能够响应的查询次数。

QPS 基本类似于 TPS,不同的是:在完成一个事务时,会存在多次查询服务器,所以应该是TPS≤QPS。

另外TPS、QPS响应时间与并发用户数有关系,对应的公式是:

TPS=并发用户数/平均响应时间。

当性能测试完,测试说500TPS,我们要有个大约概念,如果响应时间按1s算,那并发数就是500。

一般的标准有:

  • 互联网电子商务:10000TPS~100000TPS,例如天猫5万TPS
  • 互联网中型网站:100TPS~500TPS
  • 互联网小型网站: 50TPS~100TPS

4. CPU

CPU指标主要指的CPU利用率。

程序在运行的时候,会使用CPU做处理计算。就会占用CPU的空间,如果占用过多,系统就会出现卡顿、无响应的情况。

CPU标准:

  • CPU<20%的利用率为资源空闲
  • 在20%~60%之间表示资源使用稳定
  • 在60%~80%之间表示资源使用饱和

当>75%时,就需要关注了。

对于web端,一般指服务器的CPU。而对于移动端,常指手机的CPU 。

App的CPU一般在20-40%,最多不能超过75%,如果长时间cpu利用率过高,就会产生发烫、闪退。

5. 内存

内存主要是运行处理CPU发出的指令,在内存里处理完毕后,再反馈给CPU。

在网络上或者硬盘上加载的资源,一定会通过内存交换,可以理解为:页面加载出来的图片、文字会暂时存到内存里的,处理完成后就删掉。

内存和CPU类似,资源都是有限的,如果占用过多,会出现卡顿或闪退的现象。

内存常内存使用率做为指标,一般<70%。

6. 磁盘吞吐量

磁盘吞吐量是指单位时间内通过磁盘的数据量,主要是每秒的读、写请求大小。

一般用磁盘繁忙率来确定性能,磁盘繁忙率要<70%。

这个指标了解即可。

7. 网络吞吐量

是指有每秒有多少兆流量进出,一般情况下不能超过设备最大传输能力的70%。

这个指标了解即可。

8. 错误率

错误率=(失败事务数/事务总数)*100%。

在一定并发下,循环调用某个接口,会出现接口报错的情况。错误率正常情况下要为0。

在高并发的情况下错误率一般要低于0.6%,就是成功率要高于99.4%。

这个指标了解即可。

像CPU、内存、磁盘、网络是指服务器的资源利用率,主要是对公司内部来说。

性能测试的同学对于这些指标的标准都很清楚,对于我们产品,需要明白这些定义与具体标准即可,性能需求提不提问题都不大。

四、移动端需要关注的性能指标

1. FPS

FPS是指每秒显示的帧数,主要用来体现出app的流畅度。

App的FPS一般>24帧/秒,最好是60帧/秒。

FPS的越高并不意味着越流畅,FPS低也不意味着页面卡。

还需要关注帧率的稳定性。如果一直都是低帧率,卡顿现象感受不明显,如果帧率忽高忽低,就会有明显的掉帧、卡顿现象。

对于游戏类app帧率要求较高,对于非游戏类app,我认为只要能保证没有明显的卡顿现象就可以了。

2. 耗电量

在App中,CPU处理、蓝牙、定位、传感器、GPU(图形处理)都会加快耗电量。

对于不同的App单位时间耗电量是不同的,耗电量的标准可以通过对比得出:

  • 与历史版本间进行对比。如果新版本与上一个版本单位时间内耗电量相差过多,则需要优化。
  • 与竞品对比,如果比竞品多了10%以上的耗电量,也需要优化。

3. App启动时间

在说响应时间的时候,我们提到1-3-5原则,5s的时候用户已经开始焦虑了。

而App的启动时间,是用户感知到的第一个时间段,直接影响用户对App的首要体验,第一次留不住,让用户再回来就更难了。

App的响应时间标准是最大不能超过5s。

如果启动时间过长,该优化就优化。

当然也可以对于历史版本与竞品进行对比,看看自家App的水平在哪。像支付宝,启动时间是秒开。

性能指标一般就以上这些,大家需要理解下。

五、性能需求达不到怎么办

一般性能测试同学在测试完成后,会给出对应的性能测试报告,我们可以通过解读性能报告的内容来判断是否需要优化性能。

在我的工作经历中,很多时候会出现性能不达标的情况,如果性能需求不满足,我们可以按照以下方式确定:

1. 重新分析指标合不合理

一般在评估时会对性能要求过高,需要重新定义性能指标再做判断。

2. 判断实际性能与性能需求是否相差太多

如果相差不大,可以先发版,延期处理性能问题。

如果相差太大,不能接受,就要与研发沟通,确定是否有优化方案、优化方案内容、优化是否会导致延期。

如果会引起延期,就要和领导反馈,以及同步各方。

六、如何从产品设计上提高性能

性能问题归根到底是技术问题,而为了达到更好的性能指标,达到最好的用户体验,我们也可以从产品设计上整点花样。

  1. 采用tab页的方式:同一个页面数据过多时,使用tab页分开加载。
  2. 分页加载:一次加载10条/20条等。
  3. 尽量不采用全屏加载的方式,使用懒加载、预加载。
  4. 懒加载:比如图片先展示缩略图,然后点击查看原图。
  5. 预加载:提前把内容加载好,用户进入到页面时,可以直接看。有些app的开屏广告就是提前预加载好,用户下次点击进入时可以直接观看。
  6. 连接超时后进行情感化提示:设置超时时间10s,当超时后,通过有趣的方式提示用户。
  7. “欺骗”用户:在页面显示操作成功,但是后端还在处理。微信发朋友圈时,就算在断网的情况下也是可以发布出来,但是就自己能看到,等联网后才能成功发布出来。

上边的几种方式虽然是和技术相关的,但是这些是直接影响产品用户体验,还是需要我们产品提出。

另外对于缓解用户的焦虑感,可以使用有趣、好玩的加载动画,分散用户的注意力。

也可以采用进度条来体现系统处理的进度。对于处理时间确实很长的,给用户个大约用时,让用户有个心理预期。

七、总结

性能需求是个容易忽视,却无比重要的地方。如果你一直忽略性能需求,下次的需求文档里一定要写上。

如果你不提,一上线系统卡成狗,你是产品,就是你的锅。

本文由 @王大鹿 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

,