Str*_*rae 9 optimization performance web-applications
在我的上一个问题之后,我想了解何时优化确实值得开发人员花费时间.
是否值得花4个小时来查询速度提高20%？是的,不,也许,是的,如果......？
"浪费"7个小时将任务切换到另一种语言以节省大约40%的CPU使用量"值得"吗？
我对新项目的正常迭代是:
隐含着"编写好的,可维护的代码".
显然,大的"优化"部分发生在第2点,但通常在项目结束后审查代码时,我发现一些部分,即使他们做得好,也可以改进.这是第5点的基本原理.
为了给出最后一点的具体示例,一个简单的例子是当我期望90%的查询SELECT和10%的查询时INSERT/UPDATE,所以我对带有索引的数据库表收费.但是在6个月之后,我发现在现实生活中有10%的SELECT查询和90%的INSERT/UPDATEs,所以查询速度没有得到优化.这是第一个出现在我脑海中的例子(显然,对于最初的错误设计而言,这不仅仅是优化的"补丁").
请注意,我是一名开发人员,而不是商人 - 但我希望尽可能让我的客户尽可能地保持良心.
我的意思是,我知道如果我失去了50个小时来获得应用程序总速度的5%,并且该应用程序被10个用户使用,那么它可能不值得花时间......但它是什么时候它是什么时候？
您认为优化何时至关重要？
你通常使用什么公式,意识到优化所花费的时间(以及最终的收益)并不总是可以在纸上量化？
编辑:对不起,但我不能接受像"直到人们不抱怨id,不需要优化"这样的答案; 它可以是一个商业视图(可疑,imho),但不是开发人员或(imho)一个良好的答案.我知道,这个问题确实很主观.
我同意Cheeso,性能优化应推迟,对项目的真实使用情况和负载一些分析,但small'n'quick优化可以立刻后项目结束来完成.
谢谢大家 ;)
YAGNI.除非人们抱怨,否则很多.
编辑:我建立了一个比那里的替代品略慢的库.它仍然获得了使用和分享,因为它使用起来更好,功能更强大.我继续投入功能和能力,推迟任何性能方面的工作.
在某些时候,有足够的功能和性能冒泡到列表的顶部我最终花了一些时间来进行性能提升,但只是在考虑了很长一段时间的努力之后.
我认为这是接近它的正确方法.
这里提到(至少)两类"效率":
UI应用程序(及其依赖项),其中最重要的度量是对用户的响应时间.
批处理,主要指标是总运行时间.
在第一种情况下,有关于响应时间的详细记录规则.如果您关心产品质量,则需要缩短响应时间.当然,越短越好,但断点是:
100毫秒的"立即"响应; 动画和其他"实时"活动至少需要这么快发生;
1秒钟的"不间断"响应.除此之外,用户将感到沮丧; 你还需要开始考虑在这一点上显示进度屏幕.
保留用户对焦10秒.任何比这更糟糕的用户都会生气.
如果你发现几个操作时超过10秒,你可以修复与性能问题理智的努力量(我不认为有一个硬性限制,但我个人肯定会说什么在1人为一个月,也可能是3-4个月以下的任何事情),那么你一定要付出努力来修复它.
同样地,如果你发现自己已经超过了这个1秒的门槛,那么你应该非常努力地让它更快.至少,比较的时间,将采取改善与时间您的应用程序的性能,则需重做与进度对话框和后台线程每一个缓慢的屏幕,用户可以取消-因为它是作为一个设计师提供您的责任如果应用程序太慢.
但是,不要仅仅基于此做出决定 - 用户体验也很重要.如果你需要花费一周的时间来坚持一些异步进度对话框,而花费3周的时间来让运行时间低于1秒,我仍然会选择后者.国际海事组织,如果问题在整个应用范围内,任何人月下的任何事情都是合理的; 如果它只是一个相对不频繁运行的报告,我可能会放手.
如果您的应用程序是实时的 - 例如图形相关 - 那么我会将其分类为与非实时应用程序的10秒标记相同的方式.也就是说,您需要尽一切努力加快速度.闪烁在游戏或图像编辑器中是不可接受的.口吃和故障在音频处理中是不可接受的.即使对于像文本输入这样基本的东西,除非您通过远程桌面或其他东西连接,否则在按下的键和出现的字符之间的500毫秒延迟是完全不可接受的.解决这些问题不需要太多努力.
现在对于第二个案例,我认为这个案例大多是不言而喻的.如果您正在进行批处理,那么您通常会遇到可扩展性问题.只要批次能够在分配的时间内运行,您就不需要改进它.但是如果你的数据正在增长,如果批次应该在一夜之间运行并且你开始看到它在凌晨时分进入,并在上午9:15中断人们的工作,那么显然你需要处理性能问题.
实际上,你真的不能等那么久; 一旦它无法在规定的时间内完成,你可能已经遇到了大麻烦.您必须积极监控情况并保持某种安全边际 - 比如在您开始担心之前,最多可用时间为5小时.
因此,批处理过程的答案显而易见.你有一个硬性要求,韧皮必须在一定时间内完成.因此,如果您接近边缘,必须提高性能,无论它有多么困难/昂贵. 那么问题就是改善这一过程最经济的方法是什么？
如果在问题上抛出更多硬件的成本要低得多(而且你知道这个问题真的可以通过硬件扩展),那么就不要花时间进行优化,只需购买新硬件.否则,弄清楚设计优化和硬件升级的组合将为您带来最佳投资回报率.在这一点上,这几乎完全是一个成本决定.
这就是我在这个问题上要说的全部内容.对"YAGNI"回应此事的人感到羞耻.了解或至少了解您是否"需要" 是您的职业责任.假设任何事情都可以接受,直到客户抱怨是放弃这一责任.
仅仅因为您的客户不要求它并不意味着您不需要考虑它.您的客户也不要求进行单元测试,甚至不需要合理的良好/可维护的代码,但是无论如何都要提供这些东西,因为它是您职业的一部分.在一天结束时,与任何其他以开发人员为中心的产品相比,您的客户将更快乐地获得顺畅,快速的产品.
必要时,优化是值得的.
如果我们承诺客户响应时间为5秒或更短的假期包搜索,并且系统将在单个Oracle服务器上运行(无论什么规格)并且搜索在峰值负载下花费30秒,那么优化肯定是值得的,因为否则我们不会得到报酬.
当您最初开发一个系统时,您(如果您是一名优秀的开发人员)正在设计高效的东西,而不会浪费时间进行过早优化.如果生成的系统不够快,则进行优化.但是你的问题似乎表明,如果你觉得它值得,你可能会做一些手动的额外优化.这不是一个考虑它的好方法,因为它意味着你没有牢牢考虑到可以接受的东西.在开始担心需要进行哪种优化之前,您需要与利益相关者讨论并设置某种目标.
| 归档时间： |
|
| 查看次数： |
400 次 |
| 最近记录： |