技术框架选型需考虑的性能因素

              技术框架选型需考虑的性能因素

在新产品进入研发阶段前,技术、操作系统、硬件、数据库等选型是必须要完成的一项重要工作,这是对产品非功能需求、架构设计中的各种要素及约束的综合评估,是验证将来的技术框架能否满足业务不断扩展过程中是否能持续运维扩展的综合抉择。

image.png

从上图可以看出,技术选型实际上是从不同维度对产品技术进行分解的过程,通过分析,合理分解出各项技术需求,然后对各项技术/产品需求进行综合评估并最终选择合适的框架,例如互联网时代很关键的分析指标即非功能性指标中的性能指标。

 这几年虽然会配合公司到各个地产出差做售前POC非功能技术支持或者出差到各个城商行等协助当地项目经理×××能故障解决、偶尔也应邀去当地一些互联网企业协助他们做开发框架选型技术性测试与调优等工作。

这些企业愿意投入精力做这些技术验证,主要目的是为了保证投入回报和最优化IT投入成本,例如框架公共类性能维护、容量规划性能验证、硬件平台与软件平台采购选型等非功能性测试验证来预测性能表现和容量规划以及预测公司将来业务发展增加时其架构是否能支撑住高并发、架构扩展、快速迭代快发等软件设计能力和市场发展趋势。

而我们做为专业非功能技术人员,在帮忙客户选型时,需要考虑如下四象思维:

22.png

其实就是技术人员和非技术人员不同维度去考虑,如何验证性测试,

Ø  用户关注的是用户操作的相应时间。

a)    业务操作的简易敏捷

b)    数据检索的合理性和正确性

c)    数据交互的效率等

Ø  其次是技术性角度考虑,例如

        33.png

Ø  管理员的角度考虑需要关注的性能点。

Ø  再次,站在开发(设计)人员角度去考虑

Ø   那么站在性能测试工程师的角度,我们要关注什么呢?

a)       响应时间的层次问题分解

b)       系统用户数的计算公式

c)       各服务资源利用问题分解与根源分析

d)       TPS数值的估算与计算工作和对应问题的定位分析

e)       吞吐量如何求证大小?

例如:吞吐量的计算公式

Ø  从业务角度看,吞吐量可以用:请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

Ø  从网络角度看,吞吐量可以用:字节/秒来衡量


猜你喜欢

转载自blog.51cto.com/372550/2124122