开发框架选型需考虑的性能因素
在新产品进入研发阶段前，技术、操作系统、硬件、数据库等选型是必须要完成的一项重要工作，这是对产品非功能需求、架构设计中的各种要素及约束的综合评估，是验证将来的技术框架能否满足业务不断扩展过程中是否能持续运维扩展的综合抉择。
从上图可以看出，技术选型实际上是从不同维度对产品技术进行分解的过程，通过分析，合理分解出各项技术需求，然后对各项技术/产品需求进行综合评估并最终选择合适的框架,例如互联网时代很关键的分析指标即非功能性指标中的性能指标。
从业后面这几年虽然会配合公司到各个地产出差做售前POC非功能技术支持或者出差到各个城商行等协助当地项目经理处理非功能性问题、偶尔也应邀去当地一些互联网企业协助他们做生产性能故障处理或开发框架选型等测试与调优等工作，其实在做这些非功能咨询或故障处理时，碰到的大部分问题都是框架开始设计等不成熟导致出现故障的几率占比比较高。所以很多企业为了防范未来，在新产品上架前的技术开发框架选型愿意投入精力做这些技术验证，主要目的是为了保证投入回报和最优化IT投入成本，例如框架公共类性能维护、容量规划性能验证、硬件平台与软件平台采购选型等非功能性测试验证来预测性能表现和容量规划以及预测公司将来业务发展增加时其架构是否能支撑住高并发、架构扩展、敏捷开发等软件设计能力和市场发展趋势，例如现在很多企业选型首选考虑微服务架构。
而我们做为专业非功能技术人员，在帮忙客户选型时，不能因技术而实施技术，产品最终是要给实际客户使用的，但是产品也是技术的产物，所以需要考虑如下四象思维，站在不同角色考虑非功能因素：
其实就是技术人员和非技术人员不同维度去考虑，如何验证性测试，
Ø 用户关注的是用户操作的相应时间。
a) 业务操作的简易敏捷
b) 数据检索的合理性和正确性
c) 数据交互的效率等
Ø 其次是技术性角度考虑，例如
Ø 技术管理员的角度考虑需要关注的性能点。
a) DBA角度看待数据库性能，如表锁等问题？
b) 网络管理员看是否出现网络堵塞等传输性能问题？
c） 系统运维人员看是否资源利用率是否出现瓶颈，例如磁盘空间等？
d） 中间件管理人员，检查是否出现连接数、线程数不足or内存回收异常等?
e） 架构管理人员，框架开发设计阶段考虑起可扩展性、安全性、容错性、移植性、可拆解、传输模式异步等？
Ø 再次，站在开发（设计）人员角度去考虑
a) 应用线程锁问题？
b） 索引合理性？
C） 对象释放及时？
d） 数据展现数量合理性？等
Ø 那么站在性能测试工程师的角度，我们要关注什么呢？
a) 响应时间的层次问题分解
b) 系统用户数的计算公式
c) 各服务资源利用问题分解与根源分析
d) TPS数值的估算与计算工作和对应问题的定位分析
e) 吞吐量如何求证大小？
例如：吞吐量的计算公式
Ø 从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
Ø 从网络角度看，吞吐量可以用：字节/秒来衡量
