FAQ manajemen cache

Artikel ini menyediakan jawaban atas pertanyaan umum tentang cara mengelola Azure Cache for Redis.

Penting

Azure Cache for Redis mengumumkan garis waktu penghentiannya untuk semua SKU. Sebaiknya pindahkan instans Azure Cache for Redis yang ada ke Azure Managed Redis sesegera mungkin.

Untuk informasi lebih lanjut tentang pengakhiran layanan:

• Penghentian Azure Cache for Redis: Yang Perlu Diketahui dan Cara Mempersiapkan
• Tanya Jawab Umum Penghentian Azure Cache for Redis

Bagaimana cara saya menolok ukur dan menguji performa cache saya?

• Gunakan redis-benchmark.exe untuk menguji beban server Redis Anda. Gunakan redis-benchmark.exe untuk merasakan kemungkinan throughput sebelum menulis pengujian kinerja Anda sendiri.
• Gunakan redis-cli untuk memantau cache menggunakan INFO perintah. Untuk petunjuk tentang mengunduh alat Redis, lihat Bagaimana cara menjalankan perintah Redis?
• Jika Anda menggunakan Transport Layer Security/Secure Socket Layer (TLS/SSL) pada instans cache Anda, tambahkan --tls parameter ke perintah alat Redis Anda, atau gunakan proxy seperti stunnel untuk mengaktifkan TLS/SSL.
• Redis-benchmark menggunakan port 6379 secara default. Gunakan -p parameter untuk mengganti pengaturan ini jika cache Anda menggunakan port 6380 SSL/TLS atau port 10000tingkat Enterprise .
• Jika perlu, Anda dapat mengaktifkan port non-TLS melalui portal Microsoft Azure sebelum menjalankan pengujian beban.
• Pastikan komputer virtual klien (VM) yang Anda gunakan untuk pengujian berada di wilayah yang sama dengan instans Azure Cache for Redis Anda.
• Pastikan VM klien Anda memiliki setidaknya kemampuan komputasi dan bandwidth sebanyak cache yang Anda uji. Untuk hasil terbaik, gunakan VM seri D dan seri E untuk klien Anda.
• Jika Anda menggunakan Windows, aktifkan Virtual Receive-side Scaling (VRSS) di komputer klien. Untuk informasi selengkapnya, lihat Penskalaan Sisi Penerimaan Virtual di Windows Server 2012 R2.
• Aktifkan diagnostik cache sehingga Anda dapat memantau kesehatan cache Anda. Anda dapat melihat metrik di portal Microsoft Azure, dan Anda juga dapat mengunduh dan meninjau metrik menggunakan alat pilihan Anda.
• Jika beban Anda menyebabkan fragmentasi memori yang tinggi, tingkatkan skala ke ukuran cache yang lebih besar.

Contoh berikut menunjukkan cara menggunakan redis-benchmark.exe. Jalankan perintah ini dari VM di wilayah yang sama dengan cache Anda untuk hasil yang akurat.

Pertama, uji permintaan yang dialurkan SET menggunakan payload 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Setelah Anda menjalankan SET pengujian, jalankan permintaan yang dialurkan GET menggunakan payload 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

Bagaimana cara mengaktifkan GC server untuk mendapatkan lebih banyak throughput pada klien saat menggunakan StackExchange.Redis?

Mengaktifkan pengumpulan sampah server (GC) dapat mengoptimalkan klien dan memberikan performa dan throughput yang lebih baik saat Anda menggunakan StackExchange.Redis. Untuk informasi selengkapnya tentang GC server dan cara mengaktifkannya, lihat artikel berikut ini:

• <Elemen gcServer>
• Dasar-dasar pengumpulan sampah
• Pengumpulan dan performa sampah

Haruskah saya mengaktifkan port non-TLS/SSL untuk terhubung ke Redis?

Server Redis tidak mendukung Transport Layer Security (TLS) secara asli, tetapi Azure Cache for Redis mendukung TLS. Jika Anda tersambung ke Azure Cache for Redis dengan klien seperti StackExchange.Redis yang mendukung TLS, gunakan TLS.

Catatan

Port non-TLS dinonaktifkan secara default untuk instans Azure Redis baru. Jika klien Anda tidak mendukung TLS, aktifkan port non-TLS dengan mengikuti petunjuk di Port akses.

Jika cache menggunakan TLS, Anda harus mengaktifkan TLS dengan menggunakan --tls opsi untuk alat Redis seperti redis-cli. Anda juga dapat menggunakan utilitas seperti stunnel untuk menyambungkan alat dengan aman ke port TLS dengan mengikuti petunjuk dalam posting blog Mengumumkan Penyedia Status Sesi ASP.NET untuk Rilis Pratinjau Redis .

Untuk petunjuk tentang mengunduh alat Redis, lihat Bagaimana cara menjalankan perintah Redis?

Apa saja pertimbangan untuk menggunakan perintah Redis umum?

• Hindari menggunakan perintah Redis tertentu yang membutuhkan waktu lama untuk diselesaikan, kecuali jika Anda sepenuhnya memahami hasil perintah ini. Misalnya, jangan menjalankan perintah KEYS dalam produksi. Tergantung pada jumlah kunci, ini bisa memerlukan waktu lama untuk dikembalikan. Redis adalah server berutas tunggal yang memproses perintah satu per satu. Jika Anda mengeluarkan KEYS perintah, Redis tidak memproses perintah berikutnya hingga selesai memproses KEYS perintah.

  Situs redis.io memiliki detail kompleksitas waktu untuk setiap operasi yang didukungnya. Pilih setiap perintah untuk melihat kompleksitas setiap operasi.

• Ukuran kunci yang akan digunakan tergantung pada skenarionya. Jika skenario Anda memerlukan tombol yang lebih besar, Anda dapat menyesuaikan ConnectionTimeoutnilai , lalu coba lagi, dan menyesuaikan logika coba lagi. Dari perspektif server Redis, nilai kunci yang lebih kecil memberikan kinerja yang lebih baik.

• Pertimbangan ini tidak berarti bahwa Anda tidak dapat menyimpan nilai yang lebih besar di Redis, tetapi latensi lebih tinggi. Jika Anda memiliki satu kumpulan data yang lebih besar dari yang lain, Anda dapat menggunakan beberapa ConnectionMultiplexer instans, masing-masing dikonfigurasi dengan serangkaian nilai batas waktu dan coba lagi yang berbeda. Untuk informasi selengkapnya, lihat Apa yang dilakukan opsi konfigurasi StackExchange.Redis?

Apa saja pertimbangan performa untuk koneksi?

Setiap tingkat harga Azure Cache for Redis memiliki batas yang berbeda untuk koneksi klien, memori, dan bandwidth. Meskipun setiap ukuran cache memungkinkan hingga beberapa jumlah koneksi, setiap koneksi ke Redis melibatkan overhead terkait. Contoh overhead tersebut adalah penggunaan CPU dan memori karena enkripsi TLS/SSL.

Batas sambungan maksimum untuk ukuran cache tertentu mengasumsikan cache yang dimuat dengan ringan. Jika beban dari overhead koneksi ditambah beban dari operasi klien melebihi kapasitas untuk sistem, cache dapat mengalami masalah kapasitas meskipun Anda tidak melebihi batas koneksi untuk ukuran cache saat ini.

Untuk informasi selengkapnya tentang batas koneksi untuk setiap tingkatan, lihat Harga Azure Cache for Redis. Untuk informasi selengkapnya tentang sambungan dan konfigurasi default lainnya, lihat Konfigurasi server Redis default.

Apa saja praktik terbaik produksi?

• Gunakan tingkat Standar atau Premium untuk sistem Produksi. Tingkat Dasar adalah sistem simpul tunggal tanpa replikasi data dan tanpa perjanjian tingkat layanan (SLA). Juga, gunakan setidaknya cache C1 untuk Produksi. Cache C0 biasanya digunakan untuk skenario pengembangan/pengujian sederhana.
• Ketahuilah bahwa Redis adalah penyimpanan data dalam memori , dan kehilangan data dapat terjadi dalam beberapa skenario. Untuk informasi selengkapnya, lihat Memecahkan masalah kehilangan data di Azure Cache for Redis.
• Kembangkan sistem Anda sehingga dapat menangani gangguan koneksi yang disebabkan oleh patching dan failover.
• Gunakan instans Azure Redis tingkat Premium untuk latensi dan throughput jaringan yang lebih baik, karena mereka memiliki perangkat keras yang lebih baik untuk CPU dan jaringan.

Praktik terbaik StackExchange.Redis

• Atur AbortConnect ke false, lalu biarkan sambung ConnectionMultiplexer kembali secara otomatis.
• Gunakan satu instans berumur ConnectionMultiplexer panjang daripada membuat koneksi baru untuk setiap permintaan.
• Redis bekerja paling baik dengan nilai yang lebih kecil, jadi pertimbangkan untuk memotong data yang lebih besar menjadi beberapa kunci. Misalnya, dalam Berapa rentang ukuran nilai ideal untuk redis?, 100 kb dianggap besar. Untuk informasi selengkapnya, lihat Mempertimbangkan lebih banyak kunci dan nilai yang lebih kecil.
• Konfigurasikan pengaturan ThreadPool Anda untuk menghindari kehabisan waktu.
• Gunakan setidaknya default connectTimeout 5 detik. Interval ini memberi StackExchange.Redis waktu yang cukup untuk membangun kembali koneksi jika ada blip jaringan.
• Perhatikan biaya performa yang terkait dengan berbagai operasi yang Anda jalankan. Misalnya, perintah KEYS adalah operasi O(n) dan harus dihindari. Situs redis.io memiliki detail tentang kompleksitas waktu setiap operasi yang didukungnya. Pilih setiap perintah untuk melihat kompleksitas setiap operasi.

Detail penting tentang pertumbuhan ThreadPool

Common Language Runtime (CLR) ThreadPool memiliki dua jenis utas, Worker dan I/O Completion Port (IOCP).

• WORKER Utas digunakan untuk hal-hal seperti memproses Task.Run(…)metode , atau ThreadPool.QueueUserWorkItem(…) . Berbagai komponen dalam CLR juga menggunakan utas ini ketika pekerjaan perlu terjadi pada utas latar belakang.
• IOCP utas digunakan untuk I/O asinkron, seperti saat membaca dari jaringan.

Kumpulan utas menyediakan utas pekerja baru atau utas penyelesaian I/O sesuai permintaan tanpa pembatasan apa pun hingga mencapai minimum pengaturan untuk setiap jenis utas. Secara default, jumlah minimum utas diatur ke jumlah prosesor pada sistem.

Setelah jumlah thread sibuk yang ada mencapai minimum nomor utas, ThreadPool membatasi kecepatan menyuntikkan utas baru ke satu utas per 500 milidetik.

Biasanya, jika sistem Anda mendapatkan ledakan pekerjaan yang membutuhkan IOCP utas, sistem tersebut memproses pekerjaan itu dengan cepat. Namun, jika burst lebih dari pengaturan yang dikonfigurasi minimum , ada beberapa penundaan dalam memproses beberapa pekerjaan karena ThreadPool menunggu salah satu dari dua kemungkinan:

• Utas yang ada menjadi bebas untuk memproses pekerjaan.
• Tidak ada utas yang ada menjadi gratis selama 500 ms sehingga utas baru dibuat.

Pada dasarnya, ketika jumlah Busy utas lebih besar dari Min utas, Anda mengalami penundaan 500 ms sebelum aplikasi memproses lalu lintas jaringan. Selain itu, utas yang ada yang tetap menganggur selama lebih dari 15 detik dibersihkan, dan siklus pertumbuhan dan penyusutan ini dapat berulang.

Pesan kesalahan dari StackExchange.Redis build 1.0.450 atau yang lebih baru mencetak statistik ThreadPool, seperti yang ditunjukkan dalam contoh berikut.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Contoh menunjukkan bahwa untuk IOCP utas, ada enam utas sibuk dan sistem dikonfigurasi untuk mengizinkan empat utas minimum. Dalam hal ini, klien kemungkinan akan melihat dua penundaan 500 ms, karena 6 > 4.

Catatan

StackExchange.Redis dapat mencapai batas waktu jika pertumbuhan salah satu IOCP utas atau WORKER utas dibatasi.

Sebaiknya atur nilai konfigurasi minimum untuk IOCP dan WORKER utas ke sesuatu yang lebih besar dari nilai default. Tidak ada panduan satu ukuran untuk semua tentang nilai ini, karena nilai yang tepat untuk satu aplikasi kemungkinan terlalu tinggi atau rendah untuk aplikasi lain. Pengaturan ini juga dapat memengaruhi kinerja bagian lain dari aplikasi yang rumit. Anda perlu menyempurnakan pengaturan ini dengan kebutuhan spesifik Anda. Tempat awal yang baik adalah 200 atau 300. Kemudian uji dan sesuaikan sesuai kebutuhan.

Mengonfigurasi pengaturan utas minimum

Anda dapat mengubah pengaturan ini secara terprogram dengan menggunakan metode ThreadPool.SetMinThreads (...)

Misalnya, di NET Framework, Anda mengatur nilai ini dalam Global.asax.cs dalam Application_Start metode:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }

Jika Anda menggunakan .NET Core, Anda mengatur nilai dalam Program.cs tepat sebelum panggilan ke WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Catatan

Nilai yang ditentukan oleh metode ini adalah pengaturan global yang memengaruhi seluruh AppDomain. Misalnya, jika Anda memiliki VM empat inti dan ingin mengatur minWorkerThreads dan minIoThreads ke 50 per CPU selama runtime, gunakan ThreadPool.SetMinThreads(200, 200).

Dimungkinkan juga untuk menentukan pengaturan utas minimum dengan menggunakan minIoThreadsminWorkerThreads atau di bawah <processModel> elemen konfigurasi di Machine.config. Machine.config biasanya terletak di %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Mengatur jumlah utas minimum dengan cara ini tidak disarankan karena ini adalah pengaturan di seluruh sistem. Jika Anda menetapkan utas minimum dengan cara ini, Anda harus memulai ulang kumpulan aplikasi.

Catatan

Nilai yang ditentukan oleh metode ini adalah pengaturan per inti. Misalnya, jika Anda memiliki mesin empat inti dan ingin pengaturan Anda minIoThreads menjadi 200 saat runtime, gunakan <processModel minIoThreads="50">.

Konten terkait

• Lihat FAQ Azure Cache for Redis lainnya.

Artikel ini menyediakan jawaban atas pertanyaan umum tentang cara mengelola Azure Cache for Redis.

Penting

Azure Cache for Redis mengumumkan garis waktu penghentiannya untuk semua SKU. Sebaiknya pindahkan instans Azure Cache for Redis yang ada ke Azure Managed Redis sesegera mungkin.

Untuk informasi lebih lanjut tentang pengakhiran layanan:

• Penghentian Azure Cache for Redis: Yang Perlu Diketahui dan Cara Mempersiapkan
• Tanya Jawab Umum Penghentian Azure Cache for Redis

• Gunakan redis-benchmark.exe untuk menguji beban server Redis Anda. Gunakan redis-benchmark.exe untuk merasakan kemungkinan throughput sebelum menulis pengujian kinerja Anda sendiri.
• Gunakan redis-cli untuk memantau cache menggunakan INFO perintah. Untuk petunjuk tentang mengunduh alat Redis, lihat Bagaimana cara menjalankan perintah Redis?
• Jika Anda menggunakan Transport Layer Security/Secure Socket Layer (TLS/SSL) pada instans cache Anda, tambahkan --tls parameter ke perintah alat Redis Anda, atau gunakan proxy seperti stunnel untuk mengaktifkan TLS/SSL.
• Redis-benchmark menggunakan port 6379 secara default. Gunakan -p parameter untuk mengganti pengaturan ini jika cache Anda menggunakan port 6380 SSL/TLS atau port 10000tingkat Enterprise .
• Jika perlu, Anda dapat mengaktifkan port non-TLS melalui portal Microsoft Azure sebelum menjalankan pengujian beban.
• Pastikan komputer virtual klien (VM) yang Anda gunakan untuk pengujian berada di wilayah yang sama dengan instans Azure Cache for Redis Anda.
• Pastikan VM klien Anda memiliki setidaknya kemampuan komputasi dan bandwidth sebanyak cache yang Anda uji. Untuk hasil terbaik, gunakan VM seri D dan seri E untuk klien Anda.
• Jika Anda menggunakan Windows, aktifkan Virtual Receive-side Scaling (VRSS) di komputer klien. Untuk informasi selengkapnya, lihat Penskalaan Sisi Penerimaan Virtual di Windows Server 2012 R2.
• Aktifkan diagnostik cache sehingga Anda dapat memantau kesehatan cache Anda. Anda dapat melihat metrik di portal Microsoft Azure, dan Anda juga dapat mengunduh dan meninjau metrik menggunakan alat pilihan Anda.
• Jika beban Anda menyebabkan fragmentasi memori yang tinggi, tingkatkan skala ke ukuran cache yang lebih besar.

Contoh berikut menunjukkan cara menggunakan redis-benchmark.exe. Jalankan perintah ini dari VM di wilayah yang sama dengan cache Anda untuk hasil yang akurat.

Pertama, uji permintaan yang dialurkan SET menggunakan payload 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Setelah Anda menjalankan SET pengujian, jalankan permintaan yang dialurkan GET menggunakan payload 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

Mengaktifkan pengumpulan sampah server (GC) dapat mengoptimalkan klien dan memberikan performa dan throughput yang lebih baik saat Anda menggunakan StackExchange.Redis. Untuk informasi selengkapnya tentang GC server dan cara mengaktifkannya, lihat artikel berikut ini:

• <Elemen gcServer>
• Dasar-dasar pengumpulan sampah
• Pengumpulan dan performa sampah

Server Redis tidak mendukung Transport Layer Security (TLS) secara asli, tetapi Azure Cache for Redis mendukung TLS. Jika Anda tersambung ke Azure Cache for Redis dengan klien seperti StackExchange.Redis yang mendukung TLS, gunakan TLS.

Catatan

Port non-TLS dinonaktifkan secara default untuk instans Azure Redis baru. Jika klien Anda tidak mendukung TLS, aktifkan port non-TLS dengan mengikuti petunjuk di Port akses.

Jika cache menggunakan TLS, Anda harus mengaktifkan TLS dengan menggunakan --tls opsi untuk alat Redis seperti redis-cli. Anda juga dapat menggunakan utilitas seperti stunnel untuk menyambungkan alat dengan aman ke port TLS dengan mengikuti petunjuk dalam posting blog Mengumumkan Penyedia Status Sesi ASP.NET untuk Rilis Pratinjau Redis .

Untuk petunjuk tentang mengunduh alat Redis, lihat Bagaimana cara menjalankan perintah Redis?

• Hindari menggunakan perintah Redis tertentu yang membutuhkan waktu lama untuk diselesaikan, kecuali jika Anda sepenuhnya memahami hasil perintah ini. Misalnya, jangan menjalankan perintah KEYS dalam produksi. Tergantung pada jumlah kunci, ini bisa memerlukan waktu lama untuk dikembalikan. Redis adalah server berutas tunggal yang memproses perintah satu per satu. Jika Anda mengeluarkan KEYS perintah, Redis tidak memproses perintah berikutnya hingga selesai memproses KEYS perintah.

  Situs redis.io memiliki detail kompleksitas waktu untuk setiap operasi yang didukungnya. Pilih setiap perintah untuk melihat kompleksitas setiap operasi.

• Ukuran kunci yang akan digunakan tergantung pada skenarionya. Jika skenario Anda memerlukan tombol yang lebih besar, Anda dapat menyesuaikan ConnectionTimeoutnilai , lalu coba lagi, dan menyesuaikan logika coba lagi. Dari perspektif server Redis, nilai kunci yang lebih kecil memberikan kinerja yang lebih baik.

• Pertimbangan ini tidak berarti bahwa Anda tidak dapat menyimpan nilai yang lebih besar di Redis, tetapi latensi lebih tinggi. Jika Anda memiliki satu kumpulan data yang lebih besar dari yang lain, Anda dapat menggunakan beberapa ConnectionMultiplexer instans, masing-masing dikonfigurasi dengan serangkaian nilai batas waktu dan coba lagi yang berbeda. Untuk informasi selengkapnya, lihat Apa yang dilakukan opsi konfigurasi StackExchange.Redis?

Setiap tingkat harga Azure Cache for Redis memiliki batas yang berbeda untuk koneksi klien, memori, dan bandwidth. Meskipun setiap ukuran cache memungkinkan hingga beberapa jumlah koneksi, setiap koneksi ke Redis melibatkan overhead terkait. Contoh overhead tersebut adalah penggunaan CPU dan memori karena enkripsi TLS/SSL.

Batas sambungan maksimum untuk ukuran cache tertentu mengasumsikan cache yang dimuat dengan ringan. Jika beban dari overhead koneksi ditambah beban dari operasi klien melebihi kapasitas untuk sistem, cache dapat mengalami masalah kapasitas meskipun Anda tidak melebihi batas koneksi untuk ukuran cache saat ini.

Untuk informasi selengkapnya tentang batas koneksi untuk setiap tingkatan, lihat Harga Azure Cache for Redis. Untuk informasi selengkapnya tentang sambungan dan konfigurasi default lainnya, lihat Konfigurasi server Redis default.

• Gunakan tingkat Standar atau Premium untuk sistem Produksi. Tingkat Dasar adalah sistem simpul tunggal tanpa replikasi data dan tanpa perjanjian tingkat layanan (SLA). Juga, gunakan setidaknya cache C1 untuk Produksi. Cache C0 biasanya digunakan untuk skenario pengembangan/pengujian sederhana.
• Ketahuilah bahwa Redis adalah penyimpanan data dalam memori , dan kehilangan data dapat terjadi dalam beberapa skenario. Untuk informasi selengkapnya, lihat Memecahkan masalah kehilangan data di Azure Cache for Redis.
• Kembangkan sistem Anda sehingga dapat menangani gangguan koneksi yang disebabkan oleh patching dan failover.
• Gunakan instans Azure Redis tingkat Premium untuk latensi dan throughput jaringan yang lebih baik, karena mereka memiliki perangkat keras yang lebih baik untuk CPU dan jaringan.

Praktik terbaik StackExchange.Redis

• Atur AbortConnect ke false, lalu biarkan sambung ConnectionMultiplexer kembali secara otomatis.
• Gunakan satu instans berumur ConnectionMultiplexer panjang daripada membuat koneksi baru untuk setiap permintaan.
• Redis bekerja paling baik dengan nilai yang lebih kecil, jadi pertimbangkan untuk memotong data yang lebih besar menjadi beberapa kunci. Misalnya, dalam Berapa rentang ukuran nilai ideal untuk redis?, 100 kb dianggap besar. Untuk informasi selengkapnya, lihat Mempertimbangkan lebih banyak kunci dan nilai yang lebih kecil.
• Konfigurasikan pengaturan ThreadPool Anda untuk menghindari kehabisan waktu.
• Gunakan setidaknya default connectTimeout 5 detik. Interval ini memberi StackExchange.Redis waktu yang cukup untuk membangun kembali koneksi jika ada blip jaringan.
• Perhatikan biaya performa yang terkait dengan berbagai operasi yang Anda jalankan. Misalnya, perintah KEYS adalah operasi O(n) dan harus dihindari. Situs redis.io memiliki detail tentang kompleksitas waktu setiap operasi yang didukungnya. Pilih setiap perintah untuk melihat kompleksitas setiap operasi.

Common Language Runtime (CLR) ThreadPool memiliki dua jenis utas, Worker dan I/O Completion Port (IOCP).

• WORKER Utas digunakan untuk hal-hal seperti memproses Task.Run(…)metode , atau ThreadPool.QueueUserWorkItem(…) . Berbagai komponen dalam CLR juga menggunakan utas ini ketika pekerjaan perlu terjadi pada utas latar belakang.
• IOCP utas digunakan untuk I/O asinkron, seperti saat membaca dari jaringan.

Kumpulan utas menyediakan utas pekerja baru atau utas penyelesaian I/O sesuai permintaan tanpa pembatasan apa pun hingga mencapai minimum pengaturan untuk setiap jenis utas. Secara default, jumlah minimum utas diatur ke jumlah prosesor pada sistem.

Setelah jumlah thread sibuk yang ada mencapai minimum nomor utas, ThreadPool membatasi kecepatan menyuntikkan utas baru ke satu utas per 500 milidetik.

Biasanya, jika sistem Anda mendapatkan ledakan pekerjaan yang membutuhkan IOCP utas, sistem tersebut memproses pekerjaan itu dengan cepat. Namun, jika burst lebih dari pengaturan yang dikonfigurasi minimum , ada beberapa penundaan dalam memproses beberapa pekerjaan karena ThreadPool menunggu salah satu dari dua kemungkinan:

• Utas yang ada menjadi bebas untuk memproses pekerjaan.
• Tidak ada utas yang ada menjadi gratis selama 500 ms sehingga utas baru dibuat.

Pada dasarnya, ketika jumlah Busy utas lebih besar dari Min utas, Anda mengalami penundaan 500 ms sebelum aplikasi memproses lalu lintas jaringan. Selain itu, utas yang ada yang tetap menganggur selama lebih dari 15 detik dibersihkan, dan siklus pertumbuhan dan penyusutan ini dapat berulang.

Pesan kesalahan dari StackExchange.Redis build 1.0.450 atau yang lebih baru mencetak statistik ThreadPool, seperti yang ditunjukkan dalam contoh berikut.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Contoh menunjukkan bahwa untuk IOCP utas, ada enam utas sibuk dan sistem dikonfigurasi untuk mengizinkan empat utas minimum. Dalam hal ini, klien kemungkinan akan melihat dua penundaan 500 ms, karena 6 > 4.

Catatan

StackExchange.Redis dapat mencapai batas waktu jika pertumbuhan salah satu IOCP utas atau WORKER utas dibatasi.

Sebaiknya atur nilai konfigurasi minimum untuk IOCP dan WORKER utas ke sesuatu yang lebih besar dari nilai default. Tidak ada panduan satu ukuran untuk semua tentang nilai ini, karena nilai yang tepat untuk satu aplikasi kemungkinan terlalu tinggi atau rendah untuk aplikasi lain. Pengaturan ini juga dapat memengaruhi kinerja bagian lain dari aplikasi yang rumit. Anda perlu menyempurnakan pengaturan ini dengan kebutuhan spesifik Anda. Tempat awal yang baik adalah 200 atau 300. Kemudian uji dan sesuaikan sesuai kebutuhan.

Mengonfigurasi pengaturan utas minimum

Anda dapat mengubah pengaturan ini secara terprogram dengan menggunakan metode ThreadPool.SetMinThreads (...)

Misalnya, di NET Framework, Anda mengatur nilai ini dalam Global.asax.cs dalam Application_Start metode:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }

Jika Anda menggunakan .NET Core, Anda mengatur nilai dalam Program.cs tepat sebelum panggilan ke WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Catatan

Nilai yang ditentukan oleh metode ini adalah pengaturan global yang memengaruhi seluruh AppDomain. Misalnya, jika Anda memiliki VM empat inti dan ingin mengatur minWorkerThreads dan minIoThreads ke 50 per CPU selama runtime, gunakan ThreadPool.SetMinThreads(200, 200).

Dimungkinkan juga untuk menentukan pengaturan utas minimum dengan menggunakan minIoThreadsminWorkerThreads atau di bawah <processModel> elemen konfigurasi di Machine.config. Machine.config biasanya terletak di %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\.

Mengatur jumlah utas minimum dengan cara ini tidak disarankan karena ini adalah pengaturan di seluruh sistem. Jika Anda menetapkan utas minimum dengan cara ini, Anda harus memulai ulang kumpulan aplikasi.

Catatan

Nilai yang ditentukan oleh metode ini adalah pengaturan per inti. Misalnya, jika Anda memiliki mesin empat inti dan ingin pengaturan Anda minIoThreads menjadi 200 saat runtime, gunakan <processModel minIoThreads="50">.

Konten terkait

• Lihat FAQ Azure Cache for Redis lainnya.