这考验研发人员思维）；或者持续重构优化；
从2分钟提升到30秒登录，但用户还是不解渴。其实P1，P2，P3三者取最长的P3是30秒，额外开销是5秒内暂时不计。
大流程P1，P2，P3已经并发运行，无可优化。但发现最长时间的P3过程中，W本地启动时总感觉太慢，不正常。
找到底层协议栈的负责人仔细code review，发现很久未修改过的底层信令协议栈，在其初始化中居然自动做了一个不必要的高层业务逻辑，额外消耗了10秒，这是不应该的。
较为底层的协议栈不应参与高层业务逻辑，它只需要为上层提供功能就可以了！修改后提升了速度到20秒。
原因：协议栈不会经常维护，开始做的时候也许不一定是高手或牛人，有些问题很隐蔽，短期不影响使用，在大数据量大压力下才能发现问题。也可能是后续图方便，为实现某个功能，不恰当的引入了BUG。
解决：协议栈必须标准化；尽量用成熟框架；尽量在初期多设计研究分析定型（各种使用者和各个软件模块多多参与）；研发组织要有核心team维护核心代码（包含协议栈）；
优化上还有很多细节（比如更细致的拆分了JSP/JS的异步更新等内容）不再详述。
用户还是不解渴，说最好10秒，且同意并要求你缓存所有必要数据，允许数据因为缓存而不同步！
那我们自然同意。我们从技术上说明了，当前模型和数据量，10秒启动是合理的，如要提升，就要权衡和牺牲。
同意用户的建议，将数据持久化到本地，启动能更快，但是数据的新鲜度（及时性）肯定会降低，有可能需要引入额外的同步刷新机制，这是一个平衡，完美的解决方案并不存在，合适就好。
最后，用户也同意了我们最开始就提出的提升硬件的要求，购买了I7六代的超级台式PC，进一步提升了（网络和对端凭他以外的本地过程）速度，这是硬件提升性能的好例子。这要看用户的预算了。
说明：本文涉及的所有专有名词，包括协议名，软件名等，皆来自于网络信息，仅供参考，如涉及版权等问题，请及时联系作者处理。
END