➕性能优化

doc/SUMMARY.md

@@ -88,6 +88,7 @@
       - [可用性](./软件工程/架构/系统设计/可用性.md)
         - [高并发](./软件工程/架构/系统设计/高并发.md)
         - [性能工程](./软件工程/性能工程.md)
+          - [性能优化](./软件工程/性能工程/性能优化.md)
         - [容量保障](./软件工程/容量保障.md)
         - [故障管理](./软件工程/架构/系统设计/故障管理.md)
           - [混沌工程](./软件工程/架构/系统设计/混沌工程.md)

doc/软件工程/性能工程/性能优化.md

@@ -0,0 +1,87 @@
+# 性能优化
+
+## 性能建模
+
+在软件设计阶段做好性能的评估分析，通过一定的方法提前识别出软件设计中潜在的性能瓶颈，并指导优化设计
+
+软件执行模型：
+
+```mermaid
+graph LR
+
+A((基本节点 t1)) --> B((循环节点 n))
+B --> C((扩展节点))
+C --> D((分支选择节点 t2))
+C --> E((执行子图))
+E --> F((分支节点 t3))
+E --> G((分支节点 t4))
+B --> H((循环体结束))
+H --> B
+A --> I((并行节点))
+I --> J((基本节点 t5))
+I --> K((基本节点 t6))
+I --> L((基本节点 t7))
+A --> M((基本节点 t8))
+
+```
+
+基于 QNM 模型的系统执行模型：
+
+```mermaid
+graph LR
+A[到达过程] --> B[排队区]
+B -- 服务请求 --> C[服务中心1]
+B -- 服务请求 --> D[服务中心2]
+C -- 完成服务 --> E[离开系统]
+D -- 完成服务 --> E
+C -- 服务请求 --> B
+D -- 服务请求 --> B
+E --> F[选择逻辑]
+F -- 直接退出 --> G[离开系统]
+F -- 排队访问磁盘 --> H[排队区]
+H -- 服务请求 --> I[服务中心3]
+I -- 完成服务 --> E
+H -- 服务请求 --> B
+```
+
+## 并行计算
+
+```mermaid
+graph LR
+A[结构数据] --> B[并行执行单元]
+C[计算逻辑] --> B
+B --> D[交互同步]
+E[内存] --> D
+F[互斥量] --> D
+G[消息队列] --> D
+H[数据库] --> D
+
+```
+
+并行执行单元的粒度可大可小，像函数、routine（协程）、actor、线程、进程、作业等。根据处理的特定领域问题，选择合适的并行执行单元粒度，并选择或定制实现相应的并发调度框架
+
+### 并行架构模式
+
+![任务线性分解架构](/assets/20230703205723.webp)
+
+触发的业务计算逻辑之间相互独立时，我们就可以通过创建多个并行执行单元，分别处理拆分后的不同子问题，并根据不同单元业务工作量的大小，建立与具体硬件线程的映射绑定关系
+
+![任务分治架构](/assets/20230703205837.webp)
+
+针对不能在系统运⾏前完成任务的拆分，而是需要动态创建任务，并借助任务队列来管理执⾏任务。这里的执⾏线程可以从队列中拉取任务，映射到硬件线程上执⾏
+
+![数据⼏何分解架构](/assets/20230703210127.webp)
+
+相同计算逻辑需要在不同的数据上进⾏运算
+
+![递归数据架构](/assets/20230703210345.webp)
+
+针对在遍历的过程中动态创建任务，然后对每个中间计算单元的运算结果逐步合并，计算得到最终的结果
+
+![数据流交互架构](/assets/20230703210452.webp)
+
+⼀个计算单元的输出刚好是另外⼀个计算单元的输⼊，并且消息交互是单向确定性的；业务场景中还会源源不断接收到新的输⼊，需要使⽤相似的计算策略进行处理，设计的核⼼就是如何⾼效实现并发计算单元间的信息交互
+
+![异步交互架构](/assets/20230703210605.webp)
+
+同⼀个任务需要与多个任务进⾏消息交互；同⼀个消息需要多个任务进⾏处理。