Kami memproses pesan melalui berbagai layanan (satu pesan akan menyentuh mungkin 9 layanan sebelum selesai, masing-masing melakukan fungsi terkait IO tertentu). Saat ini kami memiliki kombinasi kasus terburuk (serialisasi kontrak data XML) dan kasus terbaik (dalam memori MSMQ) untuk kinerja.
Sifat pesan berarti bahwa data serial kami berakhir sekitar 12-15 kilobyte, dan kami memproses sekitar 4 juta pesan per minggu. Pesan persisten di MSMQ terlalu lambat bagi kami, dan seiring bertambahnya data kami merasakan tekanan dari file yang dipetakan memori MSMQ. Server menggunakan memori 16GB dan terus bertambah, hanya untuk mengantri. Performa juga berkurang ketika penggunaan memori tinggi, saat mesin mulai bertukar. Kami sudah melakukan perilaku pembersihan-diri MSMQ.
Saya merasa ada bagian yang kita lakukan salah di sini. Saya mencoba menggunakan RavenDB untuk mempertahankan pesan dan hanya mengantri pengenal, tetapi kinerjanya sangat lambat (1000 pesan per menit, paling bagus). Saya tidak yakin apakah itu hasil dari menggunakan versi pengembangan atau apa, tapi kami jelas membutuhkan throughput yang lebih tinggi [1]. Konsep ini bekerja sangat baik dalam teori tetapi kinerja tidak sesuai dengan tugas.
Pola penggunaan memiliki satu layanan yang bertindak sebagai router, yang tidak membaca semua. Layanan lain akan melampirkan informasi berdasarkan kait pihak ke-3 mereka, dan meneruskan kembali ke router. Sebagian besar objek disentuh 9-12 kali, meskipun sekitar 10% dipaksa untuk berputar dalam sistem ini untuk sementara waktu sampai pihak ke-3 merespons dengan tepat. Layanan sekarang memperhitungkan ini dan memiliki perilaku tidur yang sesuai, karena kami memanfaatkan bidang prioritas pesan untuk alasan ini.
Jadi, pertanyaan saya, apakah tumpukan ideal untuk pengiriman pesan antara mesin diskrit-tapi-LAN dalam lingkungan C # / Windows? Saya biasanya mulai dengan BinaryFormatter daripada serialisasi XML, tapi itu lubang kelinci jika cara yang lebih baik adalah melepas serialisasi ke toko dokumen. Karena itu, pertanyaan saya.
[1]: Sifat bisnis kami berarti semakin cepat kami memproses pesan, semakin banyak uang yang kami hasilkan. Kami telah membuktikan secara empiris bahwa memproses pesan di akhir minggu berarti kami cenderung menghasilkan uang. Sementara kinerja "1000 per menit" terdengar sangat cepat, kami benar-benar membutuhkan angka tersebut di atas 10k / menit. Hanya karena saya memberikan angka dalam pesan per minggu tidak berarti kami memiliki seluruh minggu untuk memproses pesan-pesan itu.
=============== edit:
Informasi tambahan
Berdasarkan komentar, saya akan menambahkan beberapa klarifikasi:
Saya tidak yakin serialisasi adalah hambatan kami. Saya telah membuat tolok ukur aplikasi, dan meskipun serialisasi muncul di grafik panas, itu hanya bertanggung jawab atas 2,5-3% dari utilisasi CPU layanan.
Saya sebagian besar khawatir tentang permanennya pesan kami dan potensi penyalahgunaan MSMQ. Kami menggunakan pesan non-transaksional, non-persisten sehingga kami dapat terus meningkatkan kinerja, dan saya benar-benar ingin memiliki setidaknya pesan persisten sehingga mereka dapat selamat dari reboot.
Menambahkan lebih banyak RAM adalah langkah sementara. Mesin tersebut telah beralih dari 4GB -> 16GB RAM dan semakin sulit untuk menurunkannya untuk terus menambahkan lebih banyak.
Karena pola perutean bintang pada aplikasi, separuh waktu sebuah objek muncul lalu didorong ke antrian, itu tidak berubah sama sekali. Ini cocok lagi (IMO) untuk menyimpannya di semacam penyimpanan nilai kunci di tempat lain dan hanya melewati pengidentifikasi pesan.
Pola perutean bintang merupakan bagian integral dari aplikasi dan tidak akan berubah. Kami tidak dapat mengaplikasikan lipan karena setiap bagian beroperasi secara tidak serempak (dengan cara polling) dan kami ingin memusatkan perilaku coba lagi di satu tempat.
Logika aplikasi ditulis dalam C #, objeknya adalah POCO yang tidak berubah, lingkungan penyebaran target adalah Windows Server 2012, dan kami diizinkan untuk berdiri di atas mesin tambahan jika perangkat lunak tertentu hanya didukung di Linux.
Tujuan saya adalah mempertahankan throughput saat ini sekaligus mengurangi jejak memori dan meningkatkan toleransi kesalahan dengan pengeluaran modal minimum.