我被要求将一个长启动的应用程序调到短时间内

性能优化的规则之一:测量它。获取硬数字。在每一个优化阶段,都要衡量性能的增加/减少/变化的不足。你(和你的管理者)不可能在你尝试和衡量某个特定的优化之前说它会或不会起作用。在实现解决方案之前,您可以随时要求测试和度量解决方案。

性能优化的第二条规则(或任何真正的):选择你的战斗。请记住,您的经理可能对所讨论的系统非常有经验,并且可能已经知道正确的解决方案;也可能涉及其他事情(政治),因此不要在这一点上用头碰你的职位。

我同意Matthieuf的观点。最重要的是要测量它。然后,您需要分析度量,以了解哪些部分最昂贵,哪些资源(内存、CPU、网络等)是瓶颈。

如果你知道这些答案,你可以提出解决方案。您可能能够为您的解决方案创建小测试(概念证明),这样您就可以尽早向您的经理报告。

有各种各样的解决方案,例如简单地购买更多的硬件可能是最好的方法。购买更多硬件也可能没有结果,您需要进行修改。修改可以优化软件、数据库或其他软件。可能是选择更好的算法,引入缓存(以牺牲更多的内存使用)或引入多线程来利用多个CPU核心。您还可以对应用程序的“环境”进行修改,例如操作系统的配置/版本、Java虚拟机、应用服务器、数据库服务器等。所有这些组件都有可能影响性能的设置。

同样,度量、识别问题、思考解决方案、构建解决方案(可能在概念验证中)以及度量解决方案是否有效非常重要。不要陷入先选择解决方案而不知道问题所在的陷阱。

在我看来,你的职位相对较低,而你的经理们还不相信你的能力和判断力。

我不明白为什么他们希望你在不知道是否可以实现的情况下,致力于某个特定的加速。

• 也许他们真的理解了代码及其问题,并且知道一定程度的加速是可以实现的。在这种情况下,他们应该有一个好主意如何做…所以试着让他们告诉你。即使他们的想法不好,你也会因为至少给他们一次尝试而得到赞扬。

• 也许他们只是试图施加压力(或传递施加在他们身上的压力),以便让你更努力地工作。在这种情况下,我可能会给他们一个有价值但保守的估计。 然后 花些时间更彻底地调查问题。如果经过几天的研究,你发现你的“即兴”估计值明显偏离了标准,那就回到经理那里,用一个更准确的估计值。

从技术角度来说,两分钟的启动时间对我来说太过分了。应用程序一直在做什么?从文件或数据库加载数据结构?重新计算事物?分析可能有助于回答其中的一些问题,但您还需要了解系统的体系结构,以便对分析数据进行感知。

在不知道真正的问题是什么的情况下,我建议在后台进行一些不太关键的初始化的同时,尽早让服务可用。(如果从这个角度来看,您的经理缓存一些重要数据的想法可能是一个好主意。)或者,我会看看为系统实现“热备份”是否可行,或者以允许您减少启动时间的方式复制它。