Cara Merancang Adaptor Berkinerja
Untuk tujuan performa, semua adaptor harus sadar batch sehubungan dengan pengiriman batch pesan, mengirimkan batch, dan umumnya melakukan operasi pada pesan dalam batch. Adaptor harus mencoba mengekspos atribut terkait performa yang dapat dikonfigurasi, seperti ukuran batch atau jumlah byte dalam batch, yang dapat dikonfigurasi dari antarmuka pengguna waktu desain adaptor.
Seperti disebutkan sebelumnya, kirim adaptor harus selalu melakukan pengiriman non-pemblokiran untuk menghindari penurunan performa host pengiriman. Pemblokiran api Mesin Olahpesan lebih lanjut tidak disarankan.
Menulis ke dan membaca dari konteks pesan memengaruhi performa run-time. Secara umum, adaptor harus menghindari membaca, menulis, dan mempromosikan jumlah properti konteks pesan yang berlebihan. Mempromosikan properti membuat pengosongan performa tambahan karena evaluasi langganan yang terjadi pada setiap properti yang dipromosikan pada durasi. Namun, adaptor perlu mempromosikan sejumlah besar properti untuk berdampak nyata pada performa. Namun, ini adalah praktik yang baik untuk mempromosikan hanya properti yang diperlukan untuk dipromosikan.
Pembatasan Kirim dan Terima
Ketika beban pada mesin BizTalk melebihi ambang batas yang dikonfigurasi, mesin membatasi adaptor dan orkestrasi untuk memastikan performa optimal. Di sisi penerima, ketika beban kerja pada mesin melebihi ambang batas tertentu, panggilan adaptor ke IBTTransportBatch.Done diblokir hingga beban menurun cukup. Ini memaksa adaptor untuk mengirimkan pekerjaan baru ke mesin hanya ketika mesin tersedia. Di sisi kirim, ketika mesin membatasi adaptor yang mengirim pesan keluar, mesin tidak mengirimkan pesan baru untuk ditransmisikan sampai bebannya berkurang.
Untuk alasan ini, adaptor tidak perlu khawatir dengan pembatasan kecuali diperlukan, misalnya, untuk membatasi jumlah koneksi ke sistem back-end. Untuk jenis skenario ini, mesin maupun Kerangka Kerja Adapter tidak memberikan dukungan apa pun.
Anda dapat menangani pembatasan jumlah pesan yang dikirim dari adaptor pengiriman kustom dalam beberapa cara tergantung pada apakah Anda mengontrol kode sumber untuk adaptor.
pembatasan Send-Side Meningkatkan Performa
Jika Anda mengontrol kode sumber untuk adaptor, Anda dapat menentukan dari heuristik jumlah maksimum pesan yang ingin Anda miliki dalam antrean untuk dikirim kapan saja. Saat Mesin Olahpesan TransmitMessage memanggil metode dan meneruskan adaptor pengiriman pesan baru, Anda dapat memilih untuk memblokir utas atau memeriksa untuk melihat apakah jumlah pesan dalam antrean lebih besar dari nilai maksimum yang Anda tentukan sebelumnya. Jika jumlah maksimum pesan telah terlampaui, Anda dapat menggunakan Resubmit metode untuk mengirim ulang pesan ke Mesin Olahpesan. Perhatikan bahwa jika adaptor sinkron, pesan sudah akan diblokir.
Jika Anda tidak mengontrol kode sumber untuk adaptor, Anda dapat mengubah jumlah pesan yang diantrekan dengan mengubah nilai Highwatermark dalam tabel Adm_serviceclass dalam database BizTalk Management. Nilai maksimum untuk properti Highwatermark adalah 200. Anda juga dapat mengubah nilai untuk properti Lowwatermark menjadi nilai yang lebih kecil.
Ingatlah bahwa nilai properti Highwatermark untuk adaptor asinkron memperkirakan jumlah pesan yang telah diberikan Mesin Olahpesan ke adaptor. Mesin Olahpesan meneruskannya ke adaptor melalui TransmitMessage metode , Pesan-pesan ini masih dapat luar biasa dalam transmisinya—misalnya, jika adaptor belum melakukan panggilan yang sesuai ke DeleteMessagemetode , , Resubmit, MoveToNextTransportatau Microsoft.BizTalk.TransportProxy.Interop.BatchOperationType.MoveToSuspendQ . Untuk adaptor sinkron, properti Highwatermark hanya memperhitungkan jumlah pesan yang telah diteruskan oleh Mesin Olahpesan ke adaptor dengan menggunakan metode TransmitMessage karena panggilan ini memproses secara sinkron, memblokir utas Mesin Pesan panggilan.
Jika Anda menulis adaptor pengiriman untuk protokol yang secara inheren lambat di alam (seperti HTTP, FTP, atau SOAP dua arah), pertimbangkan hal berikut:
Adaptor semacam itu mungkin menerima pesan untuk transmisi dari BizTalk Messaging Engine lebih cepat daripada yang dapat mengirimkannya. Perbedaan ini menyebabkan masalah di berbagai tingkatan. Pesan di bawah transmisi tetap dalam memori dan mengambil memori virtual, memperlambat seluruh sistem.
Adaptor mungkin menggunakan sumber daya khusus protokol. Misalnya, mungkin membuka terlalu banyak koneksi bersamaan ke server, yang dapat mengganggu server jarak jauh.
Adaptor mungkin memengaruhi adaptor lain. Misalnya, jika terlalu banyak pesan mengantre untuk adaptor tertentu, Mesin Olahpesan berhenti mengeluarkan permintaan ke adaptor pengiriman lain dalam proses tersebut.
Solusinya adalah menempatkan adaptor yang lambat dan cepat di Host BizTalk terpisah dan mengontrol jumlah pesan dengan menggunakan pengaturan "Marka Air Tinggi" dan "Marka Air Rendah".
pembatasan Receive-Side Meningkatkan Performa
Ada banyak situasi di mana adaptor penerima menerima pesan lebih cepat daripada tingkat di mana sistem lainnya dapat memproses pesan. Ketika situasi seperti itu terjadi, database MessageBox menjadi backlogged. Ketika ini terjadi, performa seluruh sistem turun secara dramatis.
Jika ini terjadi dengan adaptor Anda, Anda dapat menggunakan salah satu teknik berikut untuk mengurangi kecepatan adaptor penerima:
Kurangi ukuran kumpulan utas Mesin Olahpesan. Anda dapat mengontrol jumlah utas yang digunakan Mesin Olahpesan untuk menerbitkan pesan ke dalam MessageBox. Dengan mengurangi jumlah utas, Anda mengurangi laju penerima adaptor menerima pesan ke dalam MessageBox. Pengaturan ini hanya perlu dilakukan untuk host yang sesuai dengan handler penerima untuk adaptor. Anda tidak boleh mengatur ini untuk host yang sesuai dengan handler pengiriman untuk adaptor, kecuali Anda ingin memperlambat adaptor pengiriman juga.
Kurangi ukuran batch adaptor. Sebagian besar adaptor penerima cepat menerbitkan pesan ke MessageBox dalam batch. Ukuran batch ini biasanya dapat dikonfigurasi di halaman properti lokasi penerima. Dengan mengurangi ukuran batch, Anda dapat mengurangi throughput keseluruhan pesan yang masuk ke sistem.
Ubah pengaturan khusus adapter lainnya. Setelah menyelesaikan dua langkah sebelumnya, Anda dapat mencoba menyesuaikan parameter adaptor lainnya untuk mengurangi throughput lebih lanjut. Beberapa adaptor mengekspos parameter internal yang dapat digunakan untuk mengurangi throughput. Misalnya, adaptor MQSeries memiliki pengaturan untuk "Pengiriman Yang Dipesan." Pengiriman Yang Diurutkan menentukan bahwa adaptor akan menerbitkan batch pesan, menunggunya selesai, lalu menerbitkan batch berikutnya. Dengan mengaktifkan pengaturan ini, Anda pada dasarnya menghapus semua paralelisme dari adaptor penerima. Sebaliknya, menyetel parameter dengan cara yang berlawanan dapat digunakan untuk meningkatkan tingkat penerimaan adaptor penerima.
Adaptor dapat mengirimkan batch sebanyak yang diperlukan ke proksi transportasi. Ketika sistem sangat ditekankan, panggilan ke metode Selesai dari antarmuka IBTTransportBatch akan memblokir pesan sampai sumber daya yang diperlukan dirilis ke sistem.
Rencanakan untuk Penerimaan dan Pengiriman Asinkron
API olahpesan BizTalk Server memiliki dukungan yang kaya untuk pemrograman asinkron. Jika Anda ingin menulis adaptor yang dapat diskalakan, rencanakan untuk menggunakan model asinkron sejak awal karena model asinkron memberikan konkurensi yang lebih baik.
Di sisi penerima, ketika adaptor mengirimkan batch pesan ke BizTalk Messaging Engine (dengan memanggil IBTTransportBatch::D one), Mesin Olahpesan mengantre pekerjaan menggunakan kumpulan utas internalnya dan segera kembali. Mesin memproses pesan pada utas terpisah, membiarkan adaptor bebas membaca lebih banyak pesan dari sumbernya dan mengirimkannya tanpa menunggu pemrosesan pesan sebelumnya selesai.
Di sisi kirim, adaptor Anda bisa asinkron atau sinkron. Namun, jika protokol Anda mendukung operasi asinkron, Anda harus menggunakan dukungan ini untuk menulis adaptor yang dapat diskalakan. Misalnya, adaptor pengiriman File dan HTTP sepenuhnya asinkron dan mereka melakukan sangat sedikit operasi pemblokiran/sinkron.
Operasi asinkron memastikan bahwa Mesin Olahpesan dan adaptor Anda akan terus melakukan pekerjaan masing-masing secara paralel dan tidak menunggu satu sama lain untuk pemrosesan pesan normal.
Gunakan Batching untuk Meningkatkan Performa
Batching adalah titik awal terbaik untuk menulis adaptor yang dapat diskalakan. Ini berlaku untuk adaptor sisi kirim dan sisi penerima. Setiap batch melewati transaksi database dalam BizTalk Server meskipun adaptor Anda tidak bertransaksi. Karena ada penundaan tetap yang terkait dengan setiap transaksi, Anda harus mencoba meminimalkan jumlah transaksi dengan menggabungkan lebih dari satu operasi ke dalam satu batch.
Jangan Kelaparan Kumpulan Utas .NET
Menulis adaptor BizTalk adalah latihan dalam menulis kode runtime .NET; menulis kode runtime .NET selalu merupakan latihan dalam pemrograman asinkron.
Kelaparan kumpulan utas .NET adalah risiko bagi semua pemrograman asinkron di .NET, dan sangat penting bagi programmer adaptor BizTalk untuk dihindari.
Kumpulan utas .NET adalah sumber daya terbatas tetapi dibagikan secara luas. Sangat mudah untuk menulis kode yang menggunakan salah satu utas kumpulan utas .NET dan menahannya untuk waktu yang lama, memblokir item kerja lainnya agar tidak dieksekusi.
Setiap kali Anda menggunakan BeginInvoke atau menggunakan timer, Anda menggunakan utas kumpulan utas .NET. Jika Anda memiliki beberapa pekerjaan yang harus dilakukan (misalnya menyalin pesan dari MQSeries ke BizTalk Server), Anda harus menjalankan satu item kerja (satu batch pesan ke BizTalk Server) dan kemudian mengantre ulang di kumpulan utas jika ada lebih banyak pekerjaan yang harus dilakukan. Jangan pernah duduk dalam perulangan while di utas.
Dalam istilah konkret ini berarti mengganti while perulangan dengan panggilan berulang ke BeginInvoke. Perubahan sederhana ini dapat secara dramatis meningkatkan kemampuan responsivitas dan peluasan skala untuk seluruh implementasi.
Pilih Pengukuran yang Tepat Saat Membatasi Ukuran Batch
Jika Anda mengirimkan pesan ke BizTalk Server dalam batch, jangan batasi ukuran batch hanya berdasarkan jumlah pesan. Pertimbangkan apa yang terjadi ketika adaptor telah dikonfigurasi ke batch hanya berdasarkan jumlah pesan: Jika ukuran batch adalah dua dan adaptor mendapatkan empat pesan berukuran 4 KB, 8 KB, 1 MB, dan 5MB masing-masing, batch pertama akan berukuran 12 KB, dan batch kedua akan berukuran 6 MB.
Karena BizTalk Messaging Engine memproses semua pesan dalam satu batch secara berurutan, batch kedua dalam contoh ini akan diproses jauh lebih lambat daripada batch pertama. Ini secara efektif mengurangi throughput. Cara yang lebih baik untuk menangani masalah ini adalah dengan batch berdasarkan jumlah pesan dan total byte dalam batch (yaitu, ukuran batch dalam byte). Tidak ada angka ajaib untuk total byte. Namun, dalam skenario pemrosesan normal, jika ukuran batch melebihi 1 MB, Anda akan mulai melihat konkurensi dan throughput yang buruk.
Umumnya adaptor bersifat agnostik pesan dan mereka tidak tahu ukuran pesan di lingkungan produksi. Ukuran pesan masuk kemungkinan akan bervariasi secara signifikan. Karena itu, selalu gunakan jumlah pesan dan total byte untuk membangun batch.