Produk kami dikembangkan pada platform .Net Core 2.2 menggunakan WCF 4.5 untuk berinteraksi dengan layanan klien SOAP. Selama layanan, pengembang bus data melihat beban tinggi di server. Selanjutnya, masalah dengan akses ke layanan mulai muncul. Akibatnya, ditemukan bahwa alasannya terletak pada jumlah senyawa aktif.
Ada masalah seperti koneksi habis. Mungkin timbul karena kurangnya port yang tersedia ketika membuat koneksi atau membatasi jumlah koneksi ke layanan eksternal atau internal. Ada dua solusi:
• Meningkatkan sumber daya yang tersedia,
• Mengurangi jumlah koneksi.
Opsi pertama tidak tersedia bagi kami, karena peningkatan sumber daya hanya dapat dilakukan di sisi penyedia layanan. Oleh karena itu, kami memutuskan untuk mencari opsi untuk mengoptimalkan jumlah senyawa. Pada artikel ini kita akan membahas tentang solusi yang ditemukan.

Ide
Ternyata, masalahnya adalah bahwa untuk setiap permintaan kami membuat contoh baru dari klien WCF. Ini membuatnya tidak mungkin untuk menggunakan kumpulan koneksi yang sudah diterapkan di WCF, karena kumpulan dibuat untuk setiap saluran, dan kami membuat saluran baru untuk setiap permintaan. Tentu saja, Anda dapat menulis ulang layanan yang bertanggung jawab untuk berinteraksi dengan WCF menggunakan klien WCF statis. Tetapi dalam kasus ini, kumpulan juga akan statis, yang dapat menyebabkan masalah dengan perubahan DNS,
dibahas dalam artikel ini . Ini juga berbicara tentang solusinya -
HttpClientFactory . Inti dari solusinya adalah bahwa pabrik dapat bekerja dengan kelompoknya sendiri, di mana koneksi diperbarui secara berkala. Periode pembaruan default adalah dua menit, tetapi dapat diubah.
Dalam produk kami, kami telah menggunakan HttpClientFactory untuk berinteraksi dengan layanan lain, dan menggunakan pabrik di WCF tampak seperti alternatif yang baik untuk klien WCF statis. Dalam hal ini, kami tidak perlu melakukan perubahan pada implementasi layanan WCF. Tapi mereka bisa menggunakan kolam yang bisa digunakan pabrik. Selain itu, ini memungkinkan kami untuk menyelesaikan masalah dengan otentikasi NTLM di Linux, yang
dijelaskan dalam artikel ini , karena ketika mengkonfigurasi klien http, Anda dapat mengatur skema otentikasi untuk penangan pesan.
Implementasi
Untuk bekerja dengan HttpClientFactory, cukup tambahkan deskripsi konfigurasi klien ke ConfigureServices. Di sana Anda dapat menambahkan beberapa klien bernama atau mengetik dengan konfigurasi Anda sendiri. Dalam hal ini, setiap klien akan menggunakan kumpulan koneksi sendiri. Dalam contoh, kami menggunakan klien bernama.
services.AddHttpClient("ClientName");
Di WCF, Anda dapat menambahkan penangan pesan Anda sendiri untuk klien http. Untuk melakukan ini, tambahkan delegasi diinisialisasi oleh metode ke parameter yang mengikat. Di sana, sebagai parameter input, kita mendapatkan handler yang dibuat di sisi WCF dan mengembalikan handler kita sendiri. Akibatnya, pawang yang diperoleh dari metode delegasi akan diteruskan ke desainer http klien di sisi WCF.
Jadi, mengembalikan handler dari pool pabrik, kami akan mengganti handler yang masuk dengannya. Untuk mendapatkan pawang dari kumpulan pabrik, kami menggunakan HttpMessageHandlerFactory. Dan untuk mendapatkan akses ke parameter yang mengikat, perlu untuk mengimplementasikan kelas yang diwarisi dari IEndpointBehavior. Dan kemudian menambahkannya ke klien WCF kami.
Secara skematis, algoritma untuk membuat klien baru di sisi WCF terlihat seperti ini.

Kami menerapkan CustomEndpointBehaviour.
public class CustomEndpointBehavior : IEndpointBehavior { private readonly Func<HttpMessageHandler> _httpHandler; public CustomEndpointBehavior(IHttpMessageHandlerFactory factory) {
Selanjutnya, tambahkan EndpointBehavior kami ke klien WCF.
var httpMessageHandler = serviceProvider.GetRequiredService<IHttpMessageHandlerFactory>(); var client = new WcfClient(); client.Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior(httpMessageHandler));
Sekarang ketika membuat koneksi melalui WCF, bila memungkinkan, instance handler dari pool akan digunakan. Ini akan mengurangi jumlah senyawa aktif.
Tes
Untuk verifikasi, kami mengirim 100 permintaan yang identik. Akibatnya, tanpa kolam, puncak senyawa mencapai 53, dan dengan kolam itu tidak melebihi 7.
Memantau koneksi tanpa kolam:

Pemantauan koneksi kolam:

Kesimpulan
Kami di True Engineering menerapkan kumpulan koneksi di WCF, yang tidak tergantung pada implementasi bekerja dengan klien WCF. Ini juga secara efektif menghemat sumber daya di sisi server tempat aplikasi berjalan, dan di sisi penyedia layanan.
Kami menghabiskan banyak waktu mencari opsi pengoptimalan, tetapi solusinya sendiri ternyata singkat dan sederhana. Ambillah selagi panas)