Multi threading layanan berbasis database

Question

Pertama beberapa latar belakang masalah, kami memiliki layanan windows (C Sharp) yang menerima pesan baru dan memprosesnya. Ini didorong oleh basis data sehingga memeriksa tabel untuk catatan yang belum diproses, memprosesnya dan kemudian memperbaruinya, ini semua dilakukan dalam dua prosedur yang tersimpan, satu untuk mendapatkan pesan yang belum diproses dan yang lainnya untuk melakukan pemrosesan.

Layanan telah diidentifikasi sebagai leher botol di sistem kami, jika kami menerima volume yang lebih tinggi dari pesan yang belum diproses, layanan membutuhkan waktu lebih lama dan lebih lama untuk melewati antrian belakang.

Saya telah diminta untuk menulis ulang layanan ini untuk memanfaatkan paralelisme, fakta bahwa ini adalah single threaded diasumsikan menjadi alasan mengapa performanya sangat buruk dengan volume yang besar, namun saya memiliki beberapa keraguan tentang asumsi ini.

Garis besar pemrosesan pesan (dilakukan satu per satu):

1. Panggil getMessage sproc, simpan data yang relevan di memori
2. Panggilan processMessage sproc melewati data yang diambil sebelumnya, pesan diproses dan divalidasi kemudian ditandai sebagai diproses dalam tabel sumber

Fakta bahwa layanan ini melakukan 90% pemrosesan di lapisan DB memberi tahu saya bahwa semua masalah yang berkaitan dengan kinerja akan terikat pada penggunaan database. Saya tidak melihat manfaat dari membuat layanan ini multithreaded dan berpikir upaya harus difokuskan pada migrasi logika bisnis dari sprocs ke layanan atau setidaknya mengoptimalkan sprocs sehingga mereka dapat dipanggil secara bersamaan tanpa menyebabkan kunci tabel atau masalah pertengkaran sumber daya lainnya .

Saya sangat menghargai masukan profesional tentang pendekatan ini karena hasil dari kinerja layanan ini akan saya terima dan saya ingin memimpin dengan harapan terbaik.

Answer 1

Pengalaman memberi tahu saya bahwa Anda 100% benar dalam tebakan Anda. Namun, pengalaman juga memberitahu saya untuk tidak pernah membuka mulut tentang sesuatu sampai saya membuktikannya.

Di sini seharusnya cukup sederhana, tambahkan beberapa metrik yang mencatat waktu yang dibutuhkan untuk memproses pesan dan berapa banyak waktu yang dihabiskan untuk setiap bit.

Tingkatkan pesan dan lihat bit mana yang mulai membutuhkan waktu lebih lama.

Anda bahkan dapat melangkah lebih jauh, cukup ubah panggilan db ke async dan jangan menunggu sampai selesai sebelum melanjutkan ke pesan berikutnya, pada dasarnya 'multi-threading' (ish) Anda app. Namun, jika Anda benar, ini akan menggiling db menjadi berhenti jadi sebaiknya jalankan pada sistem pengujian.

Setelah kesalahan jelas pada sprocs, Anda dapat menggali lebih dalam untuk mencari tahu mengapa mereka lambat, atau hanya mengeluarkan logika.