نعم ، جهاز الكمبيوتر المحمول القديم الخاص بي أقوى عدة مرات من خادم الإنتاج الخاص بك

set nocount on
create table _t (v varchar(100))
declare @n int=300000
while @n>0 begin 
  insert into _t select 'What a slowpoke!'
  delete from _t
  set @n=@n-1
  end
GO
drop table _t

(في التعليقات اتضح أنني كذبت - لقد تأخرت المتانة في كلا المكانين. بدون متانة متأخرة اتضح:
سطح المكتب - 39 ثانية ، 15 ألف طن / ثانية ، 0.065 مللي ثانية / io ذهاب وعودة
PROD - 360 ثانية ، 1600 لتر / ثانية ، 0.6 مللي ثانية
I كان يجب أن ينتبه مبكرًا)

create function dbo.isPrime (@n bigint)
returns int
as
  begin
  if @n = 1 return 0
  if @n = 2 return 1
  if @n = 3 return 1
  if @n % 2 = 0 return 0
  declare @sq int
  set @sq = sqrt(@n)+1 -- check odds up to sqrt
  declare @dv int = 1
  while @dv < @sq 
    begin
	set @dv=@dv+2
	if @n % @dv = 0 return 0
	end
  return 1
  end
GO
declare @dt datetime set @dt=getdate()
select dbo.isPrime(1000000000000037)
select datediff(ms,@dt,getdate()) as ms
GO

    class Program
    {
        [DllImport("kernel32.dll")]
        static extern void GetSystemTimePreciseAsFileTime(out FILE_TIME lpSystemTimeAsFileTime);

        [StructLayout(LayoutKind.Sequential)]
        struct FILE_TIME
        {
            public int ftTimeLow;
            public int ftTimeHigh;
        }

        static void Main(string[] args)
        {
            for (int i = 0; i < 16; i++)
            {
                int counter = 0;

                var stopwatch = Stopwatch.StartNew();

                while (stopwatch.ElapsedMilliseconds < 1000)
                {
                    GetSystemTimePreciseAsFileTime(out var fileTime);
                    counter++;
                }

                if (i > 0)
                {
                    Console.WriteLine("{0}", counter);
                }
            }
        }
    }

• هذا عادة ليس مخيفا. ولكن: عند الانتقال من مضيف "أصلي" إلى مضيف بتردد "مختلف" ، يجب على VMware ضبط نتيجة GetTimePrecise.
• كقاعدة ، هذا ليس مخيفًا ، إلا إذا كان هناك تطبيق يطلب الوقت بالضبط ملايين المرات في الثانية ، مثل خادم SQL.
• لكن هذا ليس مخيفًا ، لأن خادم SQL لا يفعل ذلك دائمًا (انظر الاستنتاج)

القرار

When you disable virtualization of the TSC, reading the TSC from within the virtual machine returns the physical machine’s TSC value, and writing the TSC from within the virtual machine has no effect. Migrating the virtual machine to another host, resuming it from suspended state, or reverting to a snapshot causes the TSC to jump discontinuously. Some guest operating systems fail to boot, or exhibit other timekeeping problems, when TSC virtualization is disabled. In the past, this feature has sometimes been recommended to improve performance of applications that read the TSC frequently, but performance of the virtual TSC has been improved substantially in current products. The feature has also been recommended for use when performing measurements that require a precise source of real time in the virtual machine.

استنتاج