算法效率分析基础
算法分析是对一个算法需要多少计算时间和存储空间作定量的分析。
分析框架
输入规模度量

算法的时间效率和空间效率都用输入规模的函数进行度量。
对相同大小的输入实例具有相同的分析结果。


对于所有的算法，对于规模更大的输入都需要运行更长的时间。
经常使用一个输入规模n为参数的函数来研究算法的效率。

运行时间的度量单位

用算法的基本操作（算法中最重要的操作）的执行次数来度量算法的时间效率。
基本操作通常是算法最内层循环中最费时的操作。
算法运行时间的估计：

$T(n) ≈ copC(n)$


n是该算法的输入规模

cop是特定计算机上一个算法基本操作的执行时间

C(n)是该算法需要执行的基本操作的次数

算法的最优、最差和平均效率

最差效率是指在输入规模为n时，算法在最坏情况下的效率。
最优效率是指在输入规模为n时，算法在最优情况下的效率。
平均效率是指在“典型”或“随机”输入的情况下，算法具有的行为（效率）。

增长次数

小规模输入在运行时间上的差别不足以将高效的算法和低效的算法区分开来。
算法效率的主要指标是基本操作次数的增长次数。
为了对这些增长次数进行比较和归类，计算机科学家们使用了3种符号：


渐近符号：

O（读“O”）：上界

Ω（读”omega”）：下界

Θ（读”theta”）：近似

存在正常数c,c1,c2和n0使得对所有n不小于n0有



更多渐近分析的符号

非紧上界记号$o$

非紧下界记号$w$

渐近符号的有用特性

当算法由两个连续执行部分组成时，该算法的整体效率由具有较大增长次数的那部分所决定。

基本的效率类型

常量( c ) < 对数( logn ) < log2n < 线性( n ) < nlogn < 平方( n2 ) <立方( n3 ) < 指数( 2n ) < 阶乘( n! )

1，目的：更好地对软件开发过程进行控制；
               提高软件的可靠性和可维护性；
               降低由复杂性引发软件错误的可能性；
               确保软件产品的质量；
               减少由软件设计方法和技巧使用不当而带来的复杂性。
2，产生原因（共6条）：需求复杂、应用要求高；开发环境复杂；软件应用框架、结构及模型复杂；软件开发过程复杂；涉及人的智力和管理复杂；项目设计与验证复杂
3，模块复杂性：模块复杂性度量主要用来对模块中的数据流和控制流结构（或模块信息流结构）和模块之间互连的复杂程度等进行度量和评价。
        模块内部结构复杂性：主要有以上两种方法，McCabe度量和Halstead度量。
        模块接口复杂性：常用模块的扇入/扇出数量或信息的扇入/扇出数量来度量。
4，复杂性控制：模块复杂性控制、模块结构复杂性控制和软件总体复杂性控制。
5，规模度量元：规模度量元Line Count复杂度；难度度量元Halstead复杂度；结构度量元McCabe复杂度
         Halstead复杂度基本思想：根据程序中可执行代码行的操作符和操作数的数量计算程序复杂性。
        McCabe复杂度基本思想：程序的复杂性很大程度上取决于程序控制流的复杂性，单一的程序顺序结构最简单，循环和选择所构成的环路越多，程序就越复杂。
        McCabe复杂度计算方法：V=E-N+2P(E表示控制流图中边的数量；N表示控制流图中节点数；P表示连接组件数目，P为1)；V=判定节点数+1；V=区域数。
       McCabe圈复杂度的应用（3点）：指出在实际测试中检测的最少基本路径的数目；McCabe圈复杂度反映模块复杂性、软件缺陷数和发现它们并改正它们所需的时间之间的关系；V(G)可用做最大模块复杂性的定量指标，大量研究表明，V(G)到10是最大上限，超过这个值会使测试变得更复杂，软件错误率增加。

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。本文意在测试apollo的高可用性与安全性。
一、测试目的
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……
在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
Apollo配置中心应运而生！
测试apollo的高可用性与安全性。
二、测试范围
本次测试包括以下几个方面：
针对配置文件的修改是否生效
模拟灾难发生（宕机或网络波动等）看是否切换备用Apollo正常工作
模拟大应用发布并发看是否Apollo能抗压正常工作
三、测试环境
3.1 逻辑拓扑



3.2 网络拓扑



3.3 软/硬件环境



四、Apollo测试项对比
针对配置文件的修改是否生效
经测试生效
通过
模拟灾难发生（宕机或网络波动等）看是否切换备用Apollo正常工作
将其中一台服务器down机后，依然可发布
通过
模拟大应用发布并发看是否Apollo能抗压正常工作
经过测试，测试apollo得到如下压测数据



同时由于整体采用apollo框架，对整体项目的压测即对apollo整体框架的压测，给出的压测结论为：
系统经过一系列业务接口的压力测试，在响应与并发量上表现优秀，期间系统稳定可靠，服务器资源波动正常，全部业务场景千万次交互错误率为0%。
业务混合模式在长达8小时（1：2：1.5充值：查询：交易）的测试场景中，压测聚合报告数据表现优秀，720万次业务交互错误率为0%，95%连接响应时间均低于1000毫秒，TPS稳定在250/sec。
通过
五、应急措施
一旦框架出现问题，可能出现的情况：

客户端无法接收到配置情况
服务端无法更新配置发布

针对以上两点，需要仔细分析框架为何会出现此问题从而解决。再次之前应急方案为手动修改配置发布。（注：无论出现何种现象只影响自动化）
六、测试结论
经过Apollo性能测试，发现此框架稳定，能够承载大量信息处理，同时与spring集成最大程度兼容和方便了研发同学的使用与对接，实现了发布自动化，并且符合运维的分布式部署与集群理念，既为当一台服务器发生故障，不影响应用使用。再权限管控方面优异，实现了角色划分，方便管控。
以下为整体可用性分析：



以上结论总结：此框架适合大型研发团体，随着团队发展壮大，使用成熟框架是势在必行，此框架符合公司需求，各个测试均通过，可以使用。



上面都是自己整理好的！我就把资料贡献出来给有需要的人！顺便求一波关注.
哈哈~各位小伙伴关注我后点击：   java架构交流群

原文链接：https://www.tuicool.com/articles/ErEVnaz

各位读者朋友新年好～
又有好长时间没有更新了，最近在研究有限元分析框架feon在grasshopper中的应用。想要实现的目标是能够在复杂结构设计的方案阶段通过简化计算模型的方式快速寻找最为合理的结构形式，结合grasshopper中遗传算法的电池实现结构找形工作。
我将这一目标拆分成几个阶段性的小目标：完成二维桁架结构的前处理工作：通过线单元的输入，根据某一点的位移、反力进行结构优化；
根据二维桁架结构的前处理代码进行扩展，增加梁单元、弹簧支座等可选功能；
基于matplotlib进行visualization功能的拓展；
拓展到三维桁架单元及三维梁单元；
*探索实体单元及网格划分并计算的可能性；
目前已经完成第一阶段的工作，中间经历了各种艰辛不去谈，既有“山重水复疑无路”的颓丧，也有“柳暗花明又一村”的喜悦。因为计算的核心功能来源于feon有限元计算框架，在理解框架结构和计算逻辑之中投入了大量的时间。结合遗传算法，就可以实现结构找形。下面通过一个动图来说明一下目前能达到的效果：遗传算法实现结构找形https://www.zhihu.com/video/1203341222930165760
以上案例设置中间腹杆端点的X坐标为参数，另一端点的竖向位移为目标值，通过对X坐标的不断筛选以寻求满足端点竖向位移最小时的最佳结构形态。
这一目标的实现主要是通过在grasshopper中编写电池完成由图形到数据的转化实现的。电池的基本构成如下：基于Feon框架的前处理电池结构线模型的输入(红色区域示意)：通过grasshopper提取曲线的端点坐标，构造出起点和终点的tuple，形成Feon框架下的Element。
力的作用点与力的大小的输入(黄色区域示意)：通过grasshopper提取点的坐标形成list，形成Feon框架下的Node。
支座点的输入(蓝色区域示意)：同力的作用点一致，形成Feon框架下的Node。
控制点的输入(绿色区域示意)：同力的作用点一致，形成Feon框架下的Node。
如果读者有疑问或建议，欢迎私信交流～
祝各位读者新年快乐！