由于没有资源可以在具有相同RAM的服务器中拥有像生产这样的数据量，磁盘和其他资源，我只是认为我们可以按比例缩小它，但仍然有测试这些更改的好方法。
当我提到缩放时，这意味着：
使用较少的100倍数据
在一台RAM和磁盘减少100倍的计算机中
将数据库实例设置为所有阈值小100倍
在生产之前，我们可能会想到许多“惊喜”问题吗？还是该方法中存在更根本的缺陷，该缺陷会导致有害更改通过测试并影响生产？
注1：我并不是为了避免针对特定更改进行特定测试而提出此方法。这只是解决未曾预料到的问题的一种方法。
注2：我并不担心测试中会通过生产的一些失败。但是我想尽可能避免这种情况。
#1 楼
这真的会在生产之前捕获我们可能预料到的许多“意外”问题吗？还是该方法中存在更根本的缺陷，该缺陷会导致有害的更改通过测试并影响生产？
明智的做法是拥有一个测试系统可以用来捕获性能问题，但是您的“扩展”方法存在缺陷。
性能不能以这种方式扩展。
在所有系统中都有瓶颈。有时，在正常或更大的负载下，我们知道这些瓶颈在哪里（内存，磁盘，网络等），但通常我们不知道。这就是为什么我们在尽可能接近生产环境的地方进行性能/负载测试的原因。
缩小系统规模并不意味着瓶颈将以类似的方式扩展。例如，将内存限制为生产的1/100可能意味着您的系统将根本无法运行。
如果要查找生产中实际会出现的瓶颈，则可以使用实际的生产系统（或非按比例缩小的副本）。
但是，如果您想了解您最近的更改是否对系统性能产生不利影响，许多人会按比例缩放它们-down系统，然后再安装更改，然后在缩减后的系统中运行相同的方案。
您将无法获得完整的图片，但是可以得到一些提示您的更改可能会在生产中进行。
（而且您可能无法捕捉到您可能会预期的许多“意外”问题，因为从定义上讲不会带来意外。）
评论
我知道扩展问题的非线性。我只是想知道在缩减的测试环境中是否有一种明显的方法可以“修复”这种方法。是的，我真的很喜欢在对测试环境进行更改之前和之后进行测试的想法。与@MichaelDurant的对话将我引向了同一点。
–亚历山大·马丁斯（Alexandre Martins）
16-3-14在18:11
#2 楼
不会。您提到的项目缩放比例非常不同，并且会使用太多因素和资源。例如，如果我使用应用程序在本地服务器上计时请求，我会发现类似1位用户= 2秒平均响应时间（每个请求的时间）
10位用户= 2.5秒平均水平
100位用户= 2.5秒平均水平
1000位用户= 20秒平均水平
10000个用户=平均10分钟
ie不线性，如@dzieciou所指出。鉴于此，这也意味着您不能只接受列出因素的1％。某些应用程序在1％时的行为不会有所不同，其他应用程序可能完全死于死锁。
因此，基本上“由于没有资源可以像批量生产那样进行生产”，这意味着您的公司不会考虑进行有用的批量测试值得花钱，否则可能需要说服。
您现在可以做的一件事是使用实时生产绩效监视，这将有助于您监视峰值和问题。许多监视服务器性能的应用程序都有显示它的图表。您至少会知道性能如何处理当前的峰值，并且能够在软件版本更改比较之前和之后做有用的事情，以查看最近的更改是否对其产生了很大影响。在开发周期中有点晚，但总比没有好。
评论
我不是在假设没有其他因素，或者缩放比例无论如何都是线性的。但是该系统已经投入生产并且已经运行了很多年。当我阅读您的答案时，我开始怀疑我们是否可以在更改之前比较性能。比较结果可能足以在进一步调查之前发出警报。我想知道是否行得通？
–亚历山大·马丁斯（Alexandre Martins）
16-3-12在21:12
是的，您可以随时监控实时生产性能，这将有助于您监控峰值和问题。许多监视服务器性能的应用程序都有显示它的图表。您至少会知道性能如何处理当前的峰值，并且可以在进行更改比较之前和之后进行有用的操作，以查看最近的更改是否对其产生了很大影响。在开发周期中有点晚，但总比没有好。将此添加到答案中。
–迈克尔·杜兰特（Michael Durrant）
16-3-12在21:27
抱歉。我的意思是比较缩小的测试环境在应用之前和之后的变化。我们已经将其用于生产，但是为时已晚。
–亚历山大·马丁斯（Alexandre Martins）
16年3月12日在21:53
#3 楼
大概数据库只是整个系统的一部分，而您的目标是确定数据库更改是否会破坏系统或减慢系统运行速度。使用缩小的数据库是检查数据库更改是否合理的方法打破事情。
我不确定使用缩小的数据库进行负载测试是否有意义。这是否有意义取决于数据库是否是瓶颈。如果您的测试数据库只有生产数据库的1％，则测试数据库可能会更快，并且可能很难分辨出速度减慢。
评论
我不是性能测试方面的专家，但我要补充一点，即系统很少线性扩展，即数据量减少100并不自动意味着系统的运行速度会快100倍。在某些阈值下，不同的行为开始起作用，包括缓存，路由平衡，内存交换等。
– dzieciou
16-3-11在19:50
@ user246您可以很好地捕捉错误作为目标。我想我可能已经将两个问题合而为一了。
–亚历山大·马丁斯（Alexandre Martins）
16年3月12日在21:06
#4 楼
测试环境不会按比例缩放。但是您可以做的是：
使测试环境尽可能类似于PROD（服务器可能更少） ，那就是我们要做的：在PROD中拥有大约一半的服务器）
复制您可以实现的大多数复杂性（像在PROD中那样使用备用服务器）
以一种合理的方式从PROD复制负载（我们收集了很少的主要类型的用户提交内容，然后使用硒在质量检查中重播）
密切监视趋势。我们使用Graphite来收集大约一百个度量标准，并对其进行密切监视。
这样的设置使您有一些机会在将代码部署到PROD之前检测性能问题，即使这远非万无一失。 >
当然，您只会检测到“未知未知数”，而不会检测到“未知未知数”。但是您至少有机会发现它们，并在将修补程序修补到PROD之前对其进行测试。您需要管理层的理解，即即使尽了最大的努力，也不可避免地会仅在PROD中检测到某些性能问题，而这并不是没人的错-这种方法很古怪，与它相抗衡的工作很少。
此外：收益递减法则也适用：如果您的测试系统是PROD的100％镜像，则系统管理团队需要做两倍的工作才能使它们都保持运行。
#5 楼
理想情况下，最好的做法是拥有UAT或登台环境，该环境将是生产环境的精确复制品，以在此处测试您的更改
如果您的应用程序有“死”时间，即在夜间或周末，则应可以在此期间在生产环境上进行测试。
在缩小的环境上进行负载测试是“最后的选择”。通过使用探查器工具，您可能能够捕获并解决某些问题，但是由于种种原因，您永远无法分辨在繁重的生产负载下会发生什么。请参阅按比例缩小环境中的性能测试。第一部分：挑战文章，了解更多详细信息。
评论
您可能对阅读立方/平方律的自然应用感兴趣。