在客户眼中,软件速度多久能体现一次?


10

从理论上讲,客户应该能够从第一手经验中感受到软件性能的提高。

在实践中,有时改进不够明显,因此为了从改进中获利,有必要在营销中使用可引用的绩效指标以吸引客户。

我们已经知道感知性能(GUI延迟等)和服务器端性能(机器,网络,基础结构等)之间的区别。

程序员多长时间需要一次额外的工作来“编写”性能分析,而受众不是程序员,而是经理和客户?

Answers:


20

尽管@jwenting提出了一些要点,但我还是不同意总体评估。

用户通常不会注意到性能的微小改进。

这样,我可以同意。

我不同意的地方围绕此声明:

大多数面向最终用户的应用程序将大部分时间都花在等待用户输入上。

现在,在您上下跳动之前,我也同意这一说法!但是,该声明强调了一个事实,即那些不充分了解用户如何真正理解系统的人经常忽略这一事实。

用户不得不等待加载时注意到应用程序运行缓慢。用户在输入数据之间必须暂停程序时注意到它。

当用户中断与系统的自然而流畅的交互时,软件性能对于用户而言是显而易见的。

用户只有在系统运行良好且不会阻碍用户使用时,才会注意到系统性能。


5
不幸的是,一些程序员感到有必要满足用户期望的等待。前几天,我在生产代码中看到了这一点:Thread.Sleep(1000); //pretend this does more than change a 0 to a 1 in the database.
Ben L

那是合理的开发人员应该介入的代码审查。那样的话,否则对食物进行更改的人们应该撤销其决策许可。
Dan McGrath

2
另一方面,@ BenL我遇到了相反的情况,有些操作在我们快速执行之前就很慢,以至于用户认为操作未执行或失败了。
Pieter B

2
@BenL:幸运的是,现代UX明确建议使用动画而不是插入任意延迟。
rwong

5

某些性能增强并未被视为性能。客户只会注意到系统“感觉”更好。

潜意识比潜意识更快地工作。我们的大脑经过编程以提供即时反馈,并且在面对一系列任务时,我们需要一个接一个地搅拌。反馈中的轻微暂停会导致此过程脱节,从而增加压力水平。如果反馈中有暂停,人们将自动双击按钮,而无需考虑它。


是的,但是有限制。人类不会以十分之一秒的速度注意到事物,因此任何100毫秒或更短的响应都是黄金。将响应从250ms降低到100ms会使事情变得更加顺畅。从100毫秒变为40毫秒不会产生几乎相同的效果。
David Thornley'3

3

通常情况下,性能改进是如此之小,以至于客户从未直接注意到。充其量,在使用过程中,他们的应用程序流程可能会稍微流畅一些,但不足以引起人们的注意。

请记住,大多数面向最终用户的应用程序会花费大部分时间等待用户输入,而不是处理该输入。因此,即使您将处理该按钮单击并更新屏幕所需的100毫秒减少了10%,用户也几乎不会注意到,因为在此之后的10000毫秒内,她将不会对该更新后的屏幕进行任何操作。

会注意到的是sysadmin,他看到一个过去需要2个小时才能完成的批处理作业现在可以在90分钟内完成,但是他只会注意到,如果他必须等待结果并且很生气,更快的返回会中途中断他通过他的电影:)


从系统管理员的角度来看,这也可能意味着必须拥有三台而不是四台服务器来处理负载,这很重要。假设没有任何问题,我还有一个工作地点,每天要花18-20个小时。经理本来希望减少这一点。
David Thornley'3

是的,那是极端的情况。从事这样的工作,每天需要运行一次的工作需要36个小时才能完成。能够将其重构为仅需要20个小时。客户很高兴:)
jwenting 2011年

2

就像今天其他人所说的,它更多地是关于感知性能和“流动性”,而不是实际的原始速度。

这意味着您只需在软件的UI中拥有自然的感觉和节奏就可以摆脱使用较慢的系统的麻烦,而不是使某些事情变得太快而另一些事情却变得非常缓慢。(作为人类,我们很好地注意到了违规行为,因为它可能是一只老虎偷偷溜走了我们……)

这对于隐藏您无能为力的延迟至关重要,因此这是一种练习的好技能。


2

我只是想跳进这里,并提供一个不寻常的情况,...

* 客户对性能表现特别关注,并注意每一个小小的变化!

在我的领域中,我们涵盖了产品渲染,这些渲染往往会被客户自己的性能进行分析。与次要版本相比,性能下降2%可以等同于以“错误报告”的形式报告的速度下降。

论坛线程通常始于客户根据软件的各种版本对他们的场景进行基准测试,而客户实际上比开发人员自己对基准进行更多的基准测试。“在X版中渲染此场景需要1小时40分钟。现在在Y版中需要32分钟。”

“此场景在X版本中加载需要18分钟,而在Y版本中则需要4分钟。”

当应用优化时,它们非常感激,仅此一项就足以保证购买新的,非常昂贵的软件升级,有时仅进行适度的改进(例如减少10%的时间)。

在某些较大的环境中,由于某些较大的工作室使用渲染场,他们必须全天为数百台机器进行渲染,因此,当产品加速运行时,它还可以为客户节省大量金钱。加快整个制作过程的速度(当艺术家以更高的生产率创造艺术而不是等待其渲染时,甚至可能会产生更好的结果)。

因此,存在这样的领域,在这些领域中,客户真正,真正地,真正地注意到了-有时甚至比开发人员本身还要注意,这超出了UI交互概念,而交互概念更多地是关于延迟而不是吞吐量。

程序员多长时间需要一次额外的工作来“编写”性能分析,而受众不是程序员,而是经理和客户?

就我们而言,几乎所有次要版本都始终存在。速度是最主要的卖点之一,即使是最技术性的基准测试和性能分析也确实受到客户和经理的赞赏和理解。客户的感知通常就像狂暴的狼一样,渴望进行更多的优化,并试图向开发人员建议如何使事情发展得更快。在这种情况下,实际上需要纪律来抵制一些客户进一步优化的冲动,并专注于其他指标,例如可维护性和功能增强。


1

我遇到的唯一时间是:

  1. 该软件通过在同一时间范围内完成更多工作来进行改进。
  2. 脱机渲染或处理速度明显加快,但看不到。
  3. 速度提升虽然有些微不足道,但改进可以防止将来出现瓶颈
  4. 对于许多人来说,并行处理可以以相同的速度完成相同的工作。
  5. 任何时候,明显的速度提高都会严重影响生产率。

1

如果客户不会注意到速度的提高,那么开发人员为什么要进行速度改进?可能有一个很好的理由。如果对用户透明,为什么要通过该工作获利?

例如:Apple每次Mac OS X升级收费约130美元。除了售价30美元的雪豹。开发人员已经在该版本上进行了艰苦的工作,但是从用户的角度来看,几乎没有什么改进。因此,苹果决定收取最低费用。


1

程序员多长时间需要一次额外的工作来“编写”性能分析,而受众不是程序员,而是经理和客户?

我相信这取决于行业。在防御合同的古怪世界中,我们经常这样做。我们有使产品以某些方式运行的特定要求-这些性能指标并不总是与最终用户体验到的东西直接相关。我们通常会进行自己的测试,以查看产品触底的地方。两种测试都记录在报告中,并仔细考虑了其含义。

就是说,我不确定在客户和部署基础不太专业的情况下(即商业世界)它是否成立。考虑到我们确实购买了需要满足性能规格的COTS,我可以说有些采购商确实要求这样的性能规格,但是根据我的经验,我去过的COTS公司并不总是有那么多的性能分析白皮书可用。这似乎取决于行业,公司规模和竞争性质。啊...资本主义。


1
在支持许多COTS产品之后,我可以向您保证性能不是他们所关心的。用户在打给客户的电话时会很在意,从一个屏幕切换到另一个屏幕需要十分钟(我处理的实际情况是设计成本较低的COTS产品,价格超过10万)。但是,COTS制造商不会直接与愤怒的用户打交道,因此对他们而言并不重要。
HLGEM 2011年

0

我的看法是,如果性能提升不明显,那么它们就不可行。换句话说,为什么有人会为没有明显改进的软件支付更多费用?

我认为,营销方面声称性能显着下降,导致用户总体上不太重视这种说法。例如,当我想开始使用分布式版本控制时,我忽略了有关git性能的主张,因为我认为这些差异可以忽略不计。只有通过自己尝试一下,我才发现它们是可信的,尤其是与有声技术的支持相结合时。

对于与最终用户体验没有直接关系的性能提升,我将是一个例外。例如,服务器吞吐量对于购买和维护服务器的人来说很重要,即使最终用户没有发现任何差异。在那种情况下,简单的“相对于X的改进百分比”就足够了。


0

这取决于您将软件产品销售给谁。

通常,您的客户不是最终用户/日常用户。因此,通常您最终会制作更精美的报告,而不是解决性能问题。因为实际上您是在向管理层而不是最终用户销售产品。

这意味着在这种情况下,您将很难为某些性能问题进行标记,但是在使该报告自动化方面将赚钱。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.