xml地图|网站地图|网站标签 [设为首页] [加入收藏]

Core项目实战,编程匠艺

2019-10-04 14:57栏目:编程
TAG:

1.高并发响应性能非常好,官方Nginx处理静态文件并发5w/s

第十一章 追求速度

【.NET Core项目实战-统一认证平台】开篇及目录索引

2.反向代码性能非常强(可用于负载均衡)

  • 优化是一个悬浮在软件开发上的幽灵,很多编程错误都是以效率的名义犯下的。
  • “优化”指改善某个事物以使它更好,对于更好,从不同方面看,有不同的理解:1. 使程序运行速度更快;2. 减少可执行文件的大小;3. 提高代码的质量;4. 提高计算结果的准确性;5. 将启动时间减到最小;6. 增加数据的吞吐量;7. 减少存储开销。
  • 对于优化,建议如下:不要做优化。
  • 一种错误的想法:只有在开发结束使你的代码运行的不够快的情况下,再考虑是否进行优化。
  • 代码的性能由许多因素决定,包括:1. 程序执行的平台;2. 部署和安装的配置;3. 体系结构软件方面的决策;4. 低级的模块设计;5. 遗留的历史问题;6. 每行源代码的质量。
  • 要从一开始就要考虑你的程序的性能,而不是置之不理。
  • 正确的代码远远比速度快的代码重要,快速得到错误的结果是毫无意义的。所以我们应该花更多的精力去证明代码运行是正确的。

    性能问题的产生可能基于以下几个原因:

  • 复杂性。不必要的复杂性是一个杀手,需要做的工作越多,代码就会运行的越慢。
  • 间接。所有的问题都可以由一个额外的间接层来解决。但是间接也产生了大量的抽象。
  • 重复。
  • 糟糕的设计。糟糕的设计必然导致糟糕的代码,它可能是导致最基本的、最细微的和最难解决的性能问题。
  • I/O。一个总是等待输入或输出的程序,其性能注定会非常糟糕。

    为什么不进行优化呢,因为优化代码是将一种良好的特性与另一种相交换的行为,代码的某些方面将受到伤害,表现在以下几个方面:

  • 可读性的损失。大部分“优化”的代码都非常凌乱,非常难懂。
  • 复杂性的增加。复杂性是优秀代码的敌人。
  • 难以维护/扩展。优化之所以会妨碍代码的可扩展性,是因为它常常来源于进行更多的设想。
  • 引入了冲突。优化往往是基于某个平台,为一种处理器选择最优的数据类型,可能会导致其他处理器上较慢的运行速度。
  • 更多的努力。我们需要关注优化工作的优先级。

  • 寻找对代码进行优化的替代方案,你能以任何其他方式提高你的程序的性能吗?尽可能不要通过修改代码的方式进行优化。

  • 我们在做软件项目时,需求文档中很少会对性能作出规定,但是如果你的程序运行的太慢,用户就会抱怨。
  • 理解你何时才确实需要对代码进行优化,最好是从一开始就编写高效和高质量的代码。

    我们是程序的运行速度加快,可以分为以下几个步骤:

  • 确定程序运行的太慢,并证明你的确需要进行优化。
  • 找出运行的最慢的代码,以这段代码为目标。
  • 测试这段作为优化目标的代码的性能。
  • 对这段代码进行优化。
  • 测试优化后的代码是否仍然可以正常运行(非常重要)。
  • 测试速度增加了多少,并决定下一步做什么。

  • 在开始优化时,有一个清晰的目标非常重要。

  • 为了正确的进行优化,你必须很小心,以防止外部因素改变你的代码的运行方式。
  • 单独优化你的代码,与所有其他工作都分开,这样一项任务的结果就不会影响其他任务。
  • 我们应该忽略较小的效率,在97%的时间里我们都能说,不成熟的优化是万恶之源。
  • 80/20原则在程序中的运用:平均来看程序超过80%的运行时间会花在少于20%的代码上。

    查找程序中影响性能的代码段,可以采取以下的方法:

  • 在代码中随处放置一些手动的计时器进行测试。
  • 计算每个函数的调用频率。
  • 利用编译器提供的钩子,在进入和退出每个函数的地方插入你自己的计数代码。
  • 对程序计数器进行取样。
  • 通过让单个函数变慢来测试它对整个程序执行时间的影响。

  • 尝试分析几个不同的数据集,观察结果有什么不同,选择一个非常基本的数据集、一个高负荷的数据集和一些普通的数据集。

  • 性能不足的原因也许不是某个具体的函数,而是一个涉及面更大的设计上的缺陷。不要只依赖于分析器来查找程序效率低下的原因,你也许会错过重要的问题。
  • 你必须在对代码修改之前和修改之后都要对性能进行测试,以确保你的修改确实使代码不同,并却确保修改确实使代码变更更好。永远不要在没有执行前后性能评估的情况下尝试对代码进行优化。
  • 不要忘记对优化后的代码进行评测,以证明你所做的是一个成功的修改。
  • 清晰的代码要好过有限的优化。
  • 常用的优化技术包括:设计更改和代码更改。与几行糟糕的源代码相比,抵消的设计更能束缚程序的效率。
  • 大多数情况下我们的优化目标是提高代码的运行速度,优化策略是:1. 加快较慢代码的速度;2. 尽量少做较慢的事情;3. 将较慢的事情推迟到不得不进行的时候再做。
  • 设计更改是宏观层面上的优化,即在较大的范围内进行修改,以改善软件的内部设计。
  • 在对程序中使用的算法进行优化时,最好使用较快的算法来代替较慢的算法,而不要胡乱的修补算法的具体实现。

    代码更改时,通常要打开编译器优化功能,或增加优化水平,常用的方法包括:

  • 循环展开。对于主题非常短的循环,循环的框架也许比循环执行的操作本身还要耗费资源。
  • 代码内嵌。通过合并调用方和被调用方来移除对函数的调用,可以提高代码的性能。
  • 常量叠算。可以在编译时进行涉及常量值的运算,以减少运行时的工作量。
  • 移到编译时,许多条件测试可以静态的加以验证,并从代码中移除,有些测试可以完全被避免。
  • 强度折减。指用一个等价但是执行速度更快的操作来代替某个操作,通常都是位运算。
  • 子表达式。
  • 无用代码删除。

  • 我们需要在设计时就进行性能方面的考虑,在设计每个模块时,不要盲目的追求性能,如果你知道需要什么样的性能水平,那么为适当的效率而设计就会更容易一些。

  • 在优化时,要非常系统,并权衡各种因素,要有一个清晰的目标,并证明每个步骤都使你更加接近目标。让可靠的代码而不是你的直觉来引导你。

  • 优秀的程序员:1. 避免进行优化,除非证明绝对需要;2. 系统的进行优化,采用深思熟虑和经过权衡的方法;3. 在求助于代码级优化之前,积极地寻找替代方案,并尝试设计级的改进;4. 更喜欢不会破坏代码质量的优化。

  • 糟糕的程序员:1. 在证明代码速度不够之前就开始进行优化;2. 非常轻率,不进行权衡或研究就改动哪些他们认为是瓶颈的代码;3. 从不从宏观地角度考虑:他们的优化在其他代码区域和使用模式中意味着什么;4. 认为速度比代码的质量更重要。

一、背景

首先说声抱歉,可能是因为假期综合症的原因,已经很长时间没更新博客了,现在也调整的差不多了,准备还是以每周1-2篇的进度来更新博客,并完成本项目所有功能。

言归正传,本重构项目是在我根据实际需求重构,由于还未完全写完,所以也没进行压测,在2月份时,张善友老师给我留言说经过压测发现我重构的Ocelot网关功能性能较差,其中根本原因就是缓存模块,由于重构项目的缓存强依赖Redis缓存,造成性能瓶颈,发现问题后,我也第一时间进行测试,性能影响很大,经过跟张老师请教,可以使用二级缓存来解决性能问题,首先感谢张老师关注并指点迷津,于是就有了这篇文章,如何把现有缓存改成二级缓存并使用。

版权声明:本文由必发88手机在线官网发布于编程,转载请注明出处:Core项目实战,编程匠艺