Daftar langkah-langkah untuk pengujian baseline SQL Server yang pasti?

Sebelum menjalankan tes kinerja / baseline untuk aplikasi yang menggunakan SQL Server, saya ingin dapat mengatur instance ke keadaan "bersih", tanpa memulai kembali instance. Ada langkah-langkah yang cenderung saya ikuti, tetapi saya ingin membangun daftar definitif yang berada dalam urutan yang benar, dan tidak memiliki langkah-langkah yang berlebihan.

Apakah daftar langkah ini menyelesaikan pengaturan SQL Server ke keadaan "bersih"?

Apakah urutannya logis / benar?

Apakah ada langkah yang berlebihan?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Eric Higgins
sumber

FYI, DROPCLEANBUFFERSbagus untuk pengujian tetapi tidak selalu akurat. Jika Anda mereferensikan tabel volume tinggi, sangat mungkin Anda hampir selalu memiliki halaman di memori, dan waktu IO tidak akan menjadi faktor besar dalam kueri itu. Anda mungkin memberi bobot lebih pada IO daripada yang realistis dalam hal itu.

— JNK

Apakah Anda berbicara tentang pengujian di lingkungan produksi atau lingkungan pengujian yang terisolasi?

— bopapa_1979

Siapa pun yang menguji dalam lingkungan Prod harus dipecat. :) Ya, lingkungan pengujian.

— Eric Higgins

Pertama, saya akan mundur dan bertanya pengukuran apa yang Anda rencanakan untuk dikumpulkan selama tes. Jika Anda menghitung pembacaan logis dengan kueri, misalnya, maka Anda tidak perlu membebaskan cache. Saya penggemar berat menggunakan pembacaan logis karena tidak tergantung apakah data di-cache atau di disk - dan dalam produksi, sulit untuk menebak apakah data kueri akan di-cache atau tidak (kecuali jika Anda menyimpan seluruh database di memori) . Jika Anda menyetel untuk meminimalkan pembacaan logis, maka aplikasi akan berjalan lebih cepat apakah data ada dalam cache atau tidak.

Selanjutnya, saya akan mempertanyakan apa yang berubah di antara proses. Misalnya, dengan menjalankan EXEC SP_UPDATESTATS di setiap basis data seperti yang Anda sarankan, Anda akan menguji ulang statistik untuk tabel yang telah diperbarui. Namun, kecuali Anda memperbarui statistik dengan fullscan, Anda mendapatkan baris acak dari tabel - itu tidak terlalu berulang, dan saya tidak berpikir Anda benar-benar ingin melakukan itu. Sebagai gantinya, Anda mungkin ingin mengembalikan basis data di antara setiap proses sehingga Anda selalu menguji data yang persis sama. Jika tes Anda melakukan sisipan / pembaruan / penghapusan, tes tersebut mungkin memiliki profil kinerja yang berbeda pada setiap proses jika Anda tidak memulihkan database (karena mereka menambah / mengubah data, ditambah mengubah statistik pada data) - dan lebih buruk lagi,

— Brent Ozar
sumber

Poin yang sangat bagus, tujuannya adalah untuk memiliki segalanya identik antara berjalan. Pengukuran yang saya ambil dalam kasus ini @ hand adalah waktu yang dijalankan untuk fungsi tertentu dalam suatu aplikasi (x detik untuk mengembalikan daftar ke aplikasi, y detik untuk menambahkan item antrian, dll). Apa yang berubah di antara pengujian bisa berupa potongan kode aplikasi & bukan objek SQL, objek SQL dan bukan kode aplikasi, atau pengaturan tingkat instance / DB seperti konkurensi tanpa perubahan kode aplikasi. Jika saya menambahkan pemulihan dari gerbang sebelum setiap tes, bagaimana perasaan Anda tentang daftar saya di atas @ titik itu? Apakah saya kehilangan sesuatu, atau apakah urutannya perlu diperbaiki?

— Eric Higgins

Brent, apakah Anda mempertimbangkan CPU dalam pengujian Anda?

— AK

@EricHiggins Alih-alih menguji beberapa hal sekaligus, saya akan menguji potongan secara individual. Saya lebih suka menguji permintaan secara langsung dan melihat perubahan apa yang memengaruhi kinerja di sana. Misalnya, jalankan pelacakan SQL saat menjalankan fungsi tertentu di aplikasi, dan kemudian terus memutar ulang jejak tersebut saat membuat perubahan indeks / konfigurasi untuk meningkatkan kinerja, dan saksikan hal-hal seperti pembacaan logis dan metrik CPU dalam jejak.

— Brent Ozar

@AlexKuznetsov Saya bukan orang yang melakukan pengujian, sebenarnya - Eric adalah orang yang mengajukan pertanyaan. Ketika saya melakukan pekerjaan semacam ini, saya melihat metrik CPU pada tingkat permintaan serta server secara keseluruhan.

— Brent Ozar

Kami menggunakan generator beban pihak ke-3 (dan memiliki orang penuh waktu yang didedikasikan untuk pengembangan uji beban). Jadi pengujian saya tepat untuk transaksi, urutan, # pengguna, langkah-langkah tepat yang dilakukan dalam aplikasi ... semuanya. Jadi saya tidak perlu melihat metrik tipe dashboard SQL sama sekali. Perangkat lunak uji beban melacak waktu respons untuk modul aplikasi hingga milidetik. Jadi melakukan pemulihan DB adalah ide yang bagus. Saya harus memeriksa langkah-langkah lain yang saya lakukan untuk memastikan saya mencapai kondisi "Bersihkan" yang saya cari sebelum setiap putaran pengujian.

— Eric Higgins