nginx静态资源 性能_如何欺骗生产环境资源以进行性能调整

nginx静态资源 性能

Performance tuning is one of the most important and critical tasks that the SQL Server Database Administrator performs on a daily basis to keep a SQL Server running in a healthy state, by identifying the performance bottlenecks and fixing the main cause of these problems.

性能调优是SQL Server数据库管理员每天执行的最重要和关键的任务之一，通过识别性能瓶颈并解决这些问题的主要原因，以使SQL Server保持正常运行。

The best and safest way to tune your queries is to run them in a development environment. However, in most cases, the result you get from the development environment is completely different from the result that you get from production, giving you a misleading or even wrong indications about the query performance. This can be true even though you copy the same database with all indexes and statistics from the production environment to development.

调整查询的最佳和最安全的方法是在开发环境中运行它们。 但是，在大多数情况下，从开发环境中获得的结果与从生产环境中获得的结果完全不同，从而给您关于查询性能的误导甚至错误的指示。 即使您将具有所有索引和统计信息的相同数据库从生产环境复制到开发环境，这也可能是正确的。

These differences in the results mainly occur due to the hardware gap between the development environment and the production one, especially the Processor core counts and the server memory. These variables are involved heavily in the SQL Server Query Optimizer decision while creating the query execution plan, and therefore the parallel operators will not work in the same way.

结果的这些差异主要是由于开发环境和生产环境之间的硬件差距所致，尤其是处理器核心数和服务器内存。 这些变量在创建查询执行计划时会大量涉及SQL Server Query Optimizer决策，因此并行运算符将无法以相同的方式工作。

Planning to have identical development and production SQL Servers isn’t feasible, in most cases,, due to the cost that will be required in a server using for testing only. Then, in light of this, how could we over come this challenge and at least simulate production SQL queries in the development environment?

在大多数情况下，计划具有相同的开发和生产SQL Server是不可行的，因为在仅用于测试的服务器中将需要一定的成本。 然后，鉴于此，我们如何克服这一挑战并至少在开发环境中模拟生产SQL查询？

The undocumented command DBCC OPTIMIZER_WHATIF is a potential solution

未记录的命令DBCC OPTIMIZER_WHATIF是潜在的解决方案

The DBCC OPTIMIZER_WHATIF command, introduced in SQL Server 2005, allows you to simulate a production environment by hypothetically altering the SQL Server Query Optimizer perception of the SQL Server resources. What is required from you is to pass the logical CPU cores, the RAM amount and the Cost Threshold for Parallelism of the production environment to the DBCC OPTIMIZER_WHATIF command, and combine that command with the query to be tuned on the development SQL Server, you will get a near real estimates of the query execution plan on the production SQL Server. As the DBCC OPTIMIZER_WHATIF command changes how the SQL Server Query Optimizer see the server available resources.

SQL Server 2005中引入的DBCC OPTIMIZER_WHATIF命令允许您通过假设地更改SQL Server资源对SQL Server查询优化器的理解来模拟生产环境。 您需要将逻辑CPU内核，RAM量和生产环境的并行成本阈值传递给DBCC OPTIMIZER_WHATIF命令，并将该命令与要在开发SQL Server上进行调优的查询结合起来，您将获得生产SQL Server上查询执行计划的近乎真实的估计。 随着DBCC OPTIMIZER_WHATIF命令更改SQL Server查询优化器查看服务器可用资源的方式。

To see what information is available about this undocumented command, we will use the DBCC HELP command along with the Trace Flag 2588.

若要查看有关此未记录命令的可用信息，我们将使用DBCC HELP命令以及跟踪标志2588。

 
DBCC TRACEON (2588) WITH NO_INFOMSGS 
DBCC HELP ('OPTIMIZER_WHATIF') WITH NO_INFOMSGS
 

The only information that will be retrieved about DBCC OPTIMIZER_WHATIF are the results below:

以下结果将是唯一有关DBCC OPTIMIZER_WHATIF的信息：

As you can see in the results, you need to provide it with the property name or number and the value for that property. Keep in your mind when using the property names in the DBCC OPTIMIZER_WHATIF command, that they are case sensitive, even in a case of insensitive installation. No error message will be shown if an invalid name or value is passed in, so you should be careful.

从结果中可以看到，您需要为其提供属性名称或编号以及该属性的值。 使用DBCC OPTIMIZER_WHATIF命令中的属性名称时，请记住，即使在不敏感安装的情况下，它们也区分大小写。 如果传入了无效的名称或值，则不会显示任何错误消息，因此请务必小心。

The valid properties that can be overridden using the DBCC OPTIMIZER_WHATIF command are:

可以使用DBCC OPTIMIZER_WHATIF命令覆盖的有效属性是：

• Property Name: CPUs, Property number : 1.
  属性名称：CPU，属性编号：1。
• Property Name: MemoryMBs, Property number : 2.
  属性名称：MemoryMBs，属性编号：2。
• Property Name: Bits, Property number : 3.
  属性名称：位，属性编号：3。
• Property Name: ParallelCardThreshold, Property number : 4.
  属性名称：ParallelCardThreshold，属性编号：4。
• Property Name: ParallelCostThreshold, Property number : 5.
  属性名称：ParallelCostThreshold，属性编号：5。
• Property Name: ParallelCardCrossProd, Property number : 6.
  属性名称：ParallelCardCrossProd，属性编号：6。

In SQL Server 2012 a new four properties were added to that command:

在SQL Server 2012中，向该命令添加了新的四个属性：

• Property Name: LowCEThresholdFactorBy10, Property number : 7.
  属性名称：LowCEThresholdFactorBy10，属性编号：7。
• Property Name: HighCEThresholdFactorBy10, Property number : 8.
  属性名称：HighCEThresholdFactorBy10，属性编号：8。
• Property Name: CEThresholdFactorCrossover, Property number : 9.
  属性名称：CEThresholdFactorCrossover，属性编号：9。
• Property Name: DMLChangeThreshold, Property number: 10.
  属性名称：DMLChangeThreshold，属性编号：10。

The current status of the properties that can be changed by the DBCC OPTIMIZER_WHATIF command can be viewed by passing the Status statement or number zero to that command as a single parameter. Before that, we should turn on the Trace Flag 3604 in order to see the command result on the screen. The generated result depends mainly on the SQL Server version.

通过将Status语句或数字零作为单个参数传递给该命令，可以查看DBCC OPTIMIZER_WHATIF命令可以更改的属性的当前状态。 在此之前，我们应该打开跟踪标志3604以便在屏幕上查看命令结果。 生成的结果主要取决于SQL Server版本。

The below command is used to check the status of these properties on my SQL Server 2016 instance:

以下命令用于检查我SQL Server 2016实例上这些属性的状态：

 
DBCC TRACEON(3604) WITH NO_INFOMSGS
DBCC OPTIMIZER_WHATIF(0) WITH NO_INFOMSGS;
 

It can be also written as:

它也可以写成：

 
DBCC TRACEON(3604) WITH NO_INFOMSGS
DBCC OPTIMIZER_WHATIF(Status) WITH NO_INFOMSGS;
 

Both queries will return the same result, which looks like the below in my case:

这两个查询将返回相同的结果，在我的情况下，如下所示：

You can also reset all the properties values and return it to its default values, if you are afraid that someone perform any change, by passing the ResetAll parameter to the DBCC OPTIMIZER_WHATIF command as follows:

如果您担心有人执行任何更改，还可以通过将ResetAll参数传递给DBCC OPTIMIZER_WHATIF命令，来重置所有属性值，并将其恢复为默认值，如下所示：

 
DBCC OPTIMIZER_WHATIF(ResetAll) WITH NO_INFOMSGS;
 

Let us start our demo.

让我们开始演示。

In this scenario, we will be working on a development SQL Server instance with 4 CPU cores and 8 GB RAM. We have been requested to tune the performance of the below query that is slow on the production SQL Server. The development team sent the query to us with the execution plan and then we executed it on the development SQL Server:

在这种情况下，我们将研究具有4个CPU内核和8 GB RAM的开发SQL Server实例。 我们被要求调整以下查询的性能，这些查询在生产SQL Server上很慢。 开发团队将查询与执行计划一起发送给我们，然后我们在开发SQL Server上执行了该查询：

 
USE SQLShackDemo 
GO
SELECT  EMP.EmpName , EMP.EmpAddress , EMPD.DepName  
FROM Employees EMP
CROSS APPLY Employee_Department EMPD
WHERE EMP.EmpName like '%Sanya%'
ORDER BY  EMPD.DepName
OPTION (RECOMPILE)
 

The generated execution plan for that query differs from the execution plan received from the production server:

为该查询生成的执行计划与从生产服务器接收的执行计划不同：

It took 54 ms to be executed and 16ms of the CPU time as follows:

执行时间为54毫秒，CPU时间为16毫秒，如下所示：

With 19,528 byes Memory Granted and 10.7688 Estimated Subtree Cost as in the SELECT operator properties window below:

具有19,528个byes的“内存已授予”权限和“ 10.7688”的估计子树开销，如下面的SELECT运算符属性窗口所示：

The query has no problem on the development SQL Server as you can see from the statistics shown previously. In order to check the real query performance, we should simulate it on the production environment. This can be done by changing the SQL Server Query Optimizer view of the development SQL Server resources that is achieved using the DBCC OPTIMIZER_WHATIF command.

从前面显示的统计信息中可以看到，该查询在开发SQL Server上没有问题。 为了检查实际的查询性能，我们应该在生产环境中对其进行仿真。 这可以通过更改使用DBCC OPTIMIZER_WHATIF命令实现的开发SQL Server资源SQL Server查询优化器视图来完成。

The below script allows the SQL Server Query optimizer to generate an execution plan for the submitted query assuming that the SQL instance is working on a server with 80 CPU cores.

下面的脚本允许SQL Server查询优化器为提交的查询生成执行计划，前提是该SQL实例在具有80个CPU内核的服务器上运行。

Take into consideration that the DBCC OPTIMIZER_WHATIF command should be combined with the query to be tuned in the same session, as this command is working on a session scope. We turned on the Trace Flag 3604 here in order to be able to query the current properties values of the DBCC OPTIMIZER_WHATIF command:

考虑到DBCC OPTIMIZER_WHATIF命令应与要在同一会话中调优的查询结合使用，因为该命令在会话范围内起作用。 我们在这里启用了跟踪标志3604，以便能够查询DBCC OPTIMIZER_WHATIF命令的当前属性值：

 
USE SQLShackDemo 
GO
-- Simulate 80 CPU cores
DBCC OPTIMIZER_WHATIF(1,80)   
-- To be able to see the result
DBCC TRACEON(3604) WITH NO_INFOMSGS 
-- Check the current status 
DBCC OPTIMIZER_WHATIF(Status) WITH NO_INFOMSGS;   
-- The query to be tuned
SELECT  EMP.EmpName , EMP.EmpAddress , EMPD.DepName  
FROM Employees EMP
CROSS APPLY Employee_Department EMPD
WHERE EMP.EmpName like '%Sanya%'
ORDER BY  EMPD.DepName
OPTION (RECOMPILE)
 

The Recompile option is added here to make sure that a new plan will be generated for the query with the new resources.

在此处添加了“重新编译”选项，以确保将使用新资源为查询生成新计划。

In the query Messages tab, you will see that the CPUs value of the DBCC OPTIMIZER_WHATIF command is changed to be 80 as follows:

在查询消息选项卡中，您将看到DBCC OPTIMIZER_WHATIF命令的CPU值更改为80，如下所示：

… and that it took 130ms on the live server to be executed, not 54ms as previously shown on the development server, and 109ms of the CPU time, not 16ms as in the previous result:

…在实时服务器上执行需要130毫秒，而不是之前在开发服务器上显示的54毫秒，而在CPU时间上是109毫秒，而不是上一个结果16毫秒：

This is the execution plan that we have received

这是我们收到的执行计划

You can compare the Sort operator weight in the new plan after modifying the number of CPUs, which is 37%, with the old result, which is 86%, and how it is enhanced:

您可以在修改CPU数量（占37％）和旧结果（占86％）之后，在新计划中比较“排序”运算符权重，以及如何对其进行增强：

Less memory is granted to the query after modifying the number of CPUs, with 6,656 bytes compared with the 19,528 byes Memory Granted with four CPU cores previously. The Estimated Subtree Cost of the SELECT operator has increased now to 11.8752, compared to the old value 10.7688 as below:

修改CPU数量后，授予查询的内存更少，为6,656字节，而之前具有四个CPU内核的19,528 byes内存授予。 与下面的旧值10.7688相比，SELECT运算符的估计子树成本现在已增加到11.8752：

DBCC OPTIMIZER_WHATIF command can be used to alter other SQL Server resources hypothetically, as mentioned previously. Assume that we need to simulate the 80 CPU cores, the 256 GB RAM and the 64-bit system of the production server on the development server to test our query again. The query below will alter the SQL Server resources for the SQL Server Query Optimizer with the specified values, showing the results:

如前所述，可以假设使用DBCC OPTIMIZER_WHATIF命令来更改其他SQL Server资源。 假设我们需要在开发服务器上模拟80个CPU内核，256 GB RAM和生产服务器的64位系统，以再次测试我们的查询。 下面的查询将使用指定的值更改SQL Server查询优化器SQL Server资源，并显示结果：

 
USE SQLShackDemo 
GO
DBCC TRACEON(3604) WITH NO_INFOMSGS 
DBCC OPTIMIZER_WHATIF(Status) WITH NO_INFOMSG
GO
DBCC OPTIMIZER_WHATIF(CPU,80) 
-- DBCC OPTIMIZER_WHATIF(1,80)
GO
DBCC OPTIMIZER_WHATIF(MemoryMBs, 262144)
-- DBCC OPTIMIZER_WHATIF(2,262144)
GO
DBCC OPTIMIZER_WHATIF(Bits, 64)
-- DBCC OPTIMIZER_WHATIF(3,64)
GO
SELECT  EMP.EmpName , EMP.EmpAddress , EMPD.DepName  
FROM Employees EMP
CROSS APPLY Employee_Department EMPD
WHERE EMP.EmpName like '%Sanya%'
ORDER BY  EMPD.DepName
OPTION (RECOMPILE)
 

The changed memory and system bits values will be like:

更改后的内存和系统位值将类似于：

After finishing the tuning process, we need to reset all properties back to the default values and show it again:

完成调整过程后，我们需要将所有属性重置为默认值，然后再次显示：

 
DBCC OPTIMIZER_WHATIF(ResetAll) WITH NO_INFOMSGS;
DBCC TRACEON(3604) WITH NO_INFOMSGS 
DBCC OPTIMIZER_WHATIF(Status) WITH NO_INFOMSGS;
 

Back to defaults again:

再次回到默认值：

结论 (Conclusion)

DBCC OPTIMIZER_WHATIF gives us a near real estimation about how the query will perform in the production environment by spoofing the production SQL Server resources on the development SQL Server, which helps us in tuning our queries more efficiently.

DBCC OPTIMIZER_WHATIF通过在开发SQL Server上欺骗生产SQL Server资源，为我们提供了有关查询在生产环境中的性能的近乎真实的估计，这有助于我们更有效地调整查询。

In this article, you saw practically how it works and how we can get benefits from it in our performance tuning tasks.

在本文中，您实际上了解了它如何工作以及如何在性能调整任务中从中获得收益。

翻译自: https://www.sqlshack.com/how-to-spoof-production-environment-resources-for-performance-tuning/

nginx静态资源 性能