تدريب - القيام بتحسين أداء التطبيق

مكتمل

في هذا التمرين، ستلاحظ سيناريو أداء جديدا وتحله عن طريق تحسين التطبيق والاستعلامات.

تحسين أداء التطبيق عن طريق استخدام Azure SQL

وفي بعض الحالات، يمكن ترحيل تطبيق موجود ونقل حمل العمل لاستعلام SQL إلى Azure الكشف عن فرص للقيام بتحسين الاستعلامات وضبطها.

لدعم ملحق جديد لموقع ويب لطلبات AdventureWorks توفير نظام تصنيف من العملاء، تحتاج إلى إضافة جدول جديد لمجموعة كثيفة من نشاط INSERT المتزامن. لقد اختبرت حمل عمل استعلام SQL على كمبيوتر تطوير مع SQL Server 2022 يحتوي على محرك أقراص SSD محلي لقاعدة البيانات وسجل المعاملات.

عندما تقوم بنقل الاختبار الخاص بك إلى قاعدة بيانات Azure SQL باستخدام مستوى الأغراض العامة (8 vCores)، يكون حمل العمل الخاص بنشاط INSERT بطيئًا. هل عليك تغيير هدف أو مستوى الخدمة لدعم حمل العمل الجديد، أم عليك النظر في التطبيق؟

يمكنك العثور على جميع البرامج النصية لهذا التمرين في المجلد 04-Performance\tuning_applications في مستودع GitHub الذي نسخته أو الملف المضغوط الذي قمت بتنزيله.

القيام بإنشاء جدول جديد للتطبيق

في Object Explorer، حدد قاعدة بيانات AdventureWorks . استخدم File>Open>File لفتح البرنامج النصي order_rating_ddl.sql لإنشاء جدول في AdventureWorks قاعدة البيانات. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

DROP TABLE IF EXISTS SalesLT.OrderRating;
GO
CREATE TABLE SalesLT.OrderRating
(OrderRatingID int identity not null,
SalesOrderID int not null,
OrderRatingDT datetime not null,
OrderRating int not null,
OrderRatingComments char(500) not null);
GO

حدد Execute لتشغيل البرنامج النصي.

القيام بتحميل الاستعلامات لمراقبة تنفيذ الاستعلام

فدعونا الآن نقوم بتحميل بعض استعلامات T-SQL لطرق عرض الإدارة الديناميكية (DMV) لملاحظة أداء الاستعلام للاستعلامات النشطة وعمليات انتظار وI/O. تحميل كافة هذه الاستعلامات في سياق AdventureWorks قاعدة البيانات.

  1. في Object Explorer، حدد قاعدة بيانات AdventureWorks . استخدم File>Open>File لفتح البرنامج النصي sqlrequests.sql للنظر في استعلامات SQL النشطة. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
    FROM sys.dm_exec_requests er
    INNER JOIN sys.dm_exec_sessions es
    ON er.session_id = es.session_id
    AND es.is_user_process = 1;
    
  2. في Object Explorer، حدد قاعدة بيانات AdventureWorks . استخدم ملف>فتح>ملف لفتح البرنامج النصي top_waits.sql للنظر في أنواع الانتظار العلوية حسب العدد. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

    SELECT * FROM sys.dm_os_wait_stats
    ORDER BY waiting_tasks_count DESC;
    
  3. في Object Explorer، حدد قاعدة بيانات AdventureWorks . استخدم File>Open>File لفتح البرنامج النصي tlog_io.sql لمراقبة زمن الانتقال لكتابات سجل المعاملات. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

    SELECT io_stall_write_ms/num_of_writes as avg_tlog_io_write_ms, * 
    FROM sys.dm_io_virtual_file_stats
    (db_id('AdventureWorks'), 2);
    

قم بإعداد البرنامج النصي لحمل العمل للقيام بالتنفيذ

افتح البرنامج النصي لحمل العمل order_rating_insert_single.cmd وحرره.

  • استبدل الخاص بك unique_id الذي تم منحك في التمرين الأول لاسم الخادم ل -S parameter.
  • استبدل كلمة المرور التي قدمتها في نشر قاعدة البيانات من التمرين الأول ل -P parameter.
  • حفظ التغييرات على الملف.

قم بتشغيل حمل العمل

  1. ومن موجه أوامر PowerShell، قم بتغيير الدليل لنشاط هذه الوحدة:

    cd c:<base directory>\04-Performance\tuning_applications
    
  2. قم بتشغيل حمل العمل مع الأمر التالي:

    .\order_rating_insert_single.cmd
    

    يستخدم هذا البرنامج النصي برنامج ostress.exe لتشغيل 25 مستخدما متزامنا عن طريق تشغيل عبارة T-SQL التالية (في البرنامج النصي order_rating_insert_single.sql):

    DECLARE @x int;
    SET @x = 0;
    WHILE (@x < 500)
    BEGIN
    SET @x = @x + 1;
    INSERT INTO SalesLT.OrderRating
    (SalesOrderID, OrderRatingDT, OrderRating, OrderRatingComments)
    VALUES (@x, getdate(), 5, 'This was a great order');
    END
    

    ويمكنك أن ترى من خلال هذا السيناريو أنه ليس بالضبط تصورًا حقيقيًا للبيانات التي تأتي من موقع الويب. ولكنه يقوم بمحاكاة العديد من تصنيفات الطلبات التي يتم تضمينها في قاعدة البيانات.

قم بلاحظة أداء طرق DMV وحمل العمل

قم بتشغيل الاستعلامات الآن في SQL Server Management Studio التي قمت بتحميلها مسبقًا لمراقبة الأداء. قم بتشغيل الاستعلامات ل sqlrequests.sql و top_waits.sql و tlog_io.sql.

وباستخدام هذه الاستعلامات، فإنه يمكنك ملاحظة الحقائق التالية:

  • تحتوي العديد من الطلبات باستمرار على wait_type من WRITELOG بقيمة > 0.
  • WRITELOG نوع الانتظار هو أحد أعلى أعداد أنواع الانتظار.
  • متوسط وقت الكتابة إلى سجل المعاملات ( avg_tlog_io_write_ms العمود في مجموعة نتائج tlog_io.sql ) في مكان ما حوالي 2 مللي ثانية.

مدة حمل العمل هذا على مثيل SQL Server 2022 مع محرك أقراص SSD هي حوالي 10-12 ثانية. وتكون المدة الإجمالية على قاعدة بيانات Azure SQL ذات نواة Gen5 v8 هي 25 ثانية تقريبًا.

WRITELOG تشير أنواع الانتظار ذات أوقات الانتظار الأعلى إلى تدفق زمن الانتقال إلى سجل المعاملات. لا يبدو وقت انتظار 2 مللي ثانية لكل كتابة كثيرًا، ولكن على محرك الأقراص SSD المحلي، فإنه يمكن لهذا الانتظار أن يكون أقل من 1 مللي ثانية.

اتخاذ القرار

لا تكون المشكلة في النسبة المئوية العالية لنشاط كتابة السجل. مدخل Microsoft Azure sys.dm_db_resource_stats ولا تظهر أي أرقام أعلى من 20-25 بالمائة (لا تحتاج إلى الاستعلام عن هذه). وليست المشكلة في حد IOPS أيضًا. فالمشكلة هي أن حمل العمل لهذا التطبيق حساس لزمن انتقال لعمليات كتابة سجل المعاملات، ولم يتم تصميم مستوى الأغراض العامة لهذا النوع من متطلبات زمن الانتقال. زمن انتقال الإدخال/الإخراج المتوقع لقاعدة بيانات Azure SQL هو 5-7 مللي ثانية.

إشعار

تقوم قاعدة بيانات Azure SQL للغرض العام بتوثيق متوسطات زمن انتقال I/O حوالي 5-7 (كتابة) و5-10 (قراءة). من الممكن أن تقوم بتجربة أزمنة الانتقال أكثر مثل هذه الأرقام. وتكون أزمنة الانتقال للأغراض العامة الخاصة بمثيل Azure SQL المُدار متشابهة. فإذا كان التطبيق الخاص بك حساسًا جدًا لأزمنة الانتقال I/O، فقم بالنظر في مستويات العمل الهامة.

فحص البرنامج النصي order_rating_insert_single.sql workload T-SQL. كل INSERT منها هو تثبيت معاملة واحدة، والذي يتطلب تدفق سجل المعاملات.

التثبيت الواحد لكل إدراج ليس فعالًا، ولكن التطبيق لم يتأثر بقرص SSD المحلي لأن كل تثبيت كان سريعًا جدًا. يعمل مستوى تسعير الأعمال الهامة (هدف الخدمة أو SKU) على توفير محركات الأقراص SSD المحلية مع تقليل زمن الانتقال. من الممكن أن يكون هناك تحسين للتطبيق، لذلك لا يكون حمل العمل حساسا لزمن انتقال الإدخال/الإخراج لسجل المعاملات.

يمكنك تغيير دفعة T-SQL لحمل العمل لتلتف BEGIN TRAN/COMMIT TRAN حول INSERT التكرارات.

قم بتشغيل حمل العمل المعدل والأكثر كفاءة

قم بعمل تحرير على البرامج النصية وتشغيلها لمشاهدة أداء I/O أكثر كفاءة. يمكنك العثور على حمل العمل المعدل في البرنامج النصي order_rating_insert.sql .

  1. قم بإعداد البرنامج النصي لحمل العمل عن طريق تحرير order_rating_insert.cmd لاستخدام اسم الخادم وكلمة المرور الصحيحين.

  2. قم بتشغيل حمل العمل المعدل باستخدام البرنامج النصي order_rating_insert.cmd ، على غرار كيفية تشغيل البرنامج النصي لحمل العمل السابق.

قم بملاحظة النتائج الجديدة

  1. انظر إلى نتائج البرنامج النصي T-SQL ل sqlrequests.sql في SSMS. وقم بملاحظة عدد أقل بكثير من عمليات انتظار WRITELOG، ووقت الانتظار الأقل الإجمالي لعمليات الانتظار هذه.

    والآن يعمل حمل العمل بشكل أسرع بكثير مقارنة بالتنفيذ السابق. فهذا مثال على ضبط التطبيق لاستعلامات SQL التي سيتم تشغيلها داخل أو خارج Azure.

    إشعار

    يمكن تشغيل حمل العمل هذا بشكل أسرع مقابل مثيل قاعدة بيانات Azure SQL مع نوع اتصال إعادة التوجيه . يستخدم النشر الذي قمت به في هذا التمرين نوع اتصال افتراضي، وهو نوع وكيل لأنك متصل خارج Azure. وباستخدام إعادة التوجيه يمكن أن تسرع بشكل كبير حمل العمل مثل هذا، قم بالنظر إلى أوقات الإرسال والتلقي المطلوبة من العميل إلى الخادم.

  2. قم بملاحظة مدة حمل العمل. يتم تشغيل حمل العمل بسرعة كبيرة وقد يكون من الصعب ملاحظة بيانات التشخيص من الاستعلامات المستخدمة سابقًا في هذا النشاط.

    يمكن أن يساعد مفهوم «إرسال في دفعات» معظم التطبيقات، بما في ذلك تلك المتصلة بـ Azure SQL.

تلميح

يمكن أن تؤثر إدارة الموارد على Azure على المعاملات الكبيرة جدا، وستكون LOG_RATE_GOVERNORالأعراض . في هذا المثال، مسافات مسافات الأعمدة char(500) غير الفارغة وتتسبب في سجلات سجل المعاملات الكبيرة. يمكنك تحسين الأداء بشكل أكبر من خلال جعل هذا العمود عمود طول متغير.

في الوحدة التالية، ستتعرف على الأداء الذكي في Azure SQL.