![]() |
1
3
我们的系统:我不能告诉你太多,但它是一个大型SaaS应用程序,服务于许多付费客户。 我们所做的每一项性能/容量工作都是非常仔细地完成的—我们不能只是试着看看它们是否有效。
如果可能的话,我们可以在非生产系统上重现性能问题,在那里我们可以分析代码并进行实验性更改。我们不能总是使用与生产完全相同的硬件(生产有大量非常高规格的服务器;dev只有几个生产规格专用的性能测试盒)。 如果在非生产环境中无法对问题进行有意义的分析,我们将在生产环境中向代码提供一些工具(经过仔细测试以确保工具不会影响系统本身)。该仪器将被“关闭”并有选择地打开,以收集足够的数据。 一旦我们对一个问题有了一个准确的分析,我们就会研究可能的解决方案,也许会开发出原型——这些可以被测试功能的正确性。 如果有几个选择,我们通常会选择风险最小的。 然后将遵循正常的发布过程—大量的测试、代码审查等。 如果相关的话,更改可能会附带一个“恢复开关”,如果出现问题,它可以在生产中快速关闭。
|
![]() |
2
3
性能优化没有具体的主计划(比如先从软件“xyz”开始)。 一般方法:
|
![]() |
3
2
|