Tips dan Trik untuk Menemukan MST pelacakan DTA

Menurut definisi, MST adalah tolok ukur untuk mengukur performa sistem secara timbal balik menggunakan beban konstan. Berikut ini adalah situasi di mana mengetahui MST sangat berguna.

1. Ketika Anda memerlukan latensi terendah dari sistem. Melebihi hasil MST dalam backlog dalam sistem, yang memperkenalkan peningkatan latensi untuk pesan. Bahkan jika backlog hanya sementara, backlog memiliki efek langsung dan menghapus pada latensi. Jadi, mengetahui sistem Anda MST akan memberi tahu Anda throughput maksimum absolut yang harus Anda harapkan untuk dicapai sebelum latensi pemrosesan pesan individual meningkat secara dramatis (misalnya, dari detik ke menit tergantung pada konfigurasi Anda).

2. Saat membandingkan dengan sistem lain. Misalnya, jika Anda ingin memvalidasi bahwa Anda mencapai MST yang diharapkan dibandingkan dengan sistem lain (misalnya, skenario dalam topik ini, studi kasus, atau sistem lain di lingkungan Anda); mengukur MST menggunakan input yang stabil menawarkan standar yang dapat direproduksi dan tidak ambigu untuk perbandingan.

   Namun, tidak perlu dikatakan, itu bisa memakan waktu untuk mengukur MST. Oleh karena itu, sebelum Anda memulai latihan yang panjang untuk mengukurnya, Anda harus mengevaluasi manfaatnya. Sebagian besar sistem produksi tidak akan mengalami input yang stabil seperti yang diukur oleh MST, melainkan beban yang berubah dari waktu ke waktu. Profil beban inilah yang pada akhirnya harus diuji untuk mensertifikasi sistem sebelum produksi. Untungnya, Anda dapat menggunakan teknik yang sama yang digunakan untuk mengukur MST untuk mengevaluasi keberlanjutan profil beban produksi Anda. Cukup jalankan profil beban Anda cukup lama untuk menyertakan satu atau beberapa jendela retensi data database BizTalkDTADb dan amati indikator kinerja utama (KPI).

   Penting untuk memulai uji coba Anda, baik MST atau memuat profil, dengan database BizTalkDTADb kosong. Data yang disimpan dalam database BizTalkDTADb sensitif waktu dan jika tidak diperoleh kembali dari awal untuk setiap eksekusi pengujian, itu dapat membuat condong hasil Anda. Bergantung pada jendela retensi data Anda, ini dapat secara signifikan meningkatkan waktu yang diperlukan untuk menemukan MST. Untuk mengurangi hal ini, menyesuaikan beban "dengan cepat" selama uji coba dapat berguna dalam nol yang lebih cepat pada MST.

   Misalnya, jika Anda menemukan bahwa Anda telah melewati waktu jendela retensi pertama Anda dan KPI menunjukkan bahwa Anda memiliki headroom untuk throughput yang lebih tinggi yang tersisa (misalnya, waktu diam disk masih di atas nol), Anda dapat secara bertahap meningkatkan beban Anda dan mengamati efeknya. Setelah Anda menyempurnakan perkiraan MST Anda dengan cara ini, penting bagi Anda untuk melakukan uji coba yang dimulai dengan database BizTalkDTADb kosong untuk memvalidasi perkiraan Anda.

Rekomendasi

Arsitektur sistem pelacakan di BizTalk Server mampu melacak berbagai informasi dan harus dikelola dan dipantau dengan hati-hati. Faktor-faktor yang paling memengaruhi performa sistem Anda, seperti yang ditunjukkan oleh MST, adalah sebagai berikut:

• Throughput yang diinginkan untuk sistem.

• Volume informasi yang dilacak untuk setiap pesan dan instans layanan dalam sistem. Ini akan menentukan seberapa cepat ukuran database BizTalkDTADb meningkat, dan pada akhirnya seberapa sering database BizTalkDTADb harus dihapus menyeluruh untuk menghindari ketinggalan.

• Berapa lama Anda ingin menyimpan data dalam database BizTalkDTADb, yaitu, jendela retensi data. Semakin lama jendela, semakin besar database BizTalkDTADb akan tumbuh, mempengaruhi throughput.

• Apakah Anda mengarsipkan data database BizTalkDTADb serta menghapus menyeluruh, atau hanya menghapus menyeluruh untuk mempertahankan ukuran database BizTalkDTADb.

  Proses menemukan throughput berkelanjutan maksimum untuk pelacakan di BizTalk Server melibatkan tiga indikator performa utama:

• Waktu Diam Disk Fisik untuk subsistem disk file data DTAdb.

• Kedalaman penampung

• Kedalaman BizTalkDTADbData

  Temukan MST sistem Anda atau validasi throughput profil produksi Anda dengan memantau ketiga indikator performa utama ini yang mencari:

• Kedalaman tabel spool dan trackingdata yang stabil.

• Waktu diam fisik disk file data database BizTalkDTADb mendekati, tetapi tidak terus-menerus "dipatok" pada, nol.

  Menggunakan fitur pelacakan DTA memiliki dampak performa terkait. Pelacakan default dapat melacak lebih dari yang diperlukan setelah solusi dalam produksi, tetapi dapat membuat pengembangan dan pengujian awal dan penelusuran kesalahan lebih mudah dengan memberikan informasi resolusi masalah yang cukup. Oleh karena itu, kami menyarankan agar pelacakan default dibiarkan selama pengembangan dan pengujian awal. Setelah solusi yang disebarkan di BizTalk stabil dan siap untuk sertifikasi produksi, termasuk pengujian performa, disarankan agar Anda memeriksa dengan cermat jumlah informasi yang perlu dilacak dalam produksi, dan lamanya waktu yang perlu disimpan dalam database BizTalkDTADb dan menyesuaikannya.

  Misalnya, jika badan pesan tidak perlu dilacak untuk tujuan non-penolakan atau resolusi masalah, maka jangan aktifkan pelacakan isi pesan. Untuk mengilustrasikan poin ini, dalam skenario contoh yang dijelaskan dalam Skenario Pengujian untuk Mengukur MST Pelacakan DTA, ketika komponen pelacakan isi pesan dari konfigurasi pelacakan dihilangkan, MST digandakan menjadi 40 pesan/detik.

  Selain itu, perlu diingat bahwa bahkan ketika masalah terjadi, dalam banyak kasus (tetapi tidak sama sekali), pesan ditangguhkan dalam database MessageBox dan dapat diambil dan diperiksa tanpa perlu melacak isi pesan.

  Fokus pada keberlanjutan beban yang Anda tempatkan pada sistem:

• Dapatkah sistem Anda mempertahankan profil beban produksi tanpa batas waktu bahkan dengan aktivitas pemeliharaan normal?

• Bagaimana jika terjadi sesuatu yang menyebabkan sistem mempertahankan backlog, seperti pemadaman database BizTalkDTADb yang direncanakan atau tidak direncanakan?

  Ada baiknya untuk menetapkan tujuan berdasarkan skenario kasus terburuk dan menguji tujuan tersebut. Misalnya, jika Anda tahu bahwa ada siklus pemeliharaan terencana berkala yang akan mengambil database BizTalkDTADb off line, meniru pemadaman ini selama uji coba untuk mengevaluasi kemampuan sistem untuk pulih dari backlog yang dihasilkan.

Lihat juga

Mengukur Throughput Pelacakan Berkelanjutan Maksimum
Memahami Perilaku Performa Pelacakan DTA
Skenario Pengujian untuk Mengukur MST Pelacakan DTA
Panduan Ukuran Database Pelacakan