Pemecahan Masalah - Amazon ElastiCache untuk Redis
Grup keamananACL jaringanTabel ruteResolusi nama DNSMengidentifikasi masalah dengan diagnostik sisi serverValidasi konektivitas jaringanBatas terkait jaringanPenggunaan CPUKoneksi yang dihentikan dari sisi serverPemecahan masalah sisi klien untuk instans Amazon EC2Membedah waktu yang dibutuhkan untuk menyelesaikan satu permintaan tunggal

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan Masalah

Item berikut harus diverifikasi saat memecahkan masalah konektivitas yang terus terjadi ElastiCache:

Grup keamanan

Grup Keamanan adalah firewall virtual yang melindungi Anda ElastiCache klien (Instans EC2,AWS Lambdafungsi, wadah Amazon ECS, dll.) Dan ElastiCache kluster. Grup keamanan bersifat stateful, artinya bahwa setelah lalu lintas masuk atau keluar diizinkan, maka tanggapan untuk lalu lintas itu akan secara otomatis mendapat otorisasi dalam konteks grup keamanan tertentu itu.

Fitur stateful mensyaratkan grup keamanan melacak semua koneksi yang diberikan otorisasi, dan terdapat batasan untuk koneksi dilacak. Jika batas itu tercapai, maka koneksi baru akan gagal. Lihat ke bagian pemecahan masalah untuk bantuan tentang cara mengidentifikasi apakah batas telah tercapai pada klien atau sisi Elasticache.

Anda dapat memiliki satu grup keamanan yang ditetapkan pada waktu yang sama untuk klien dan ElastiCache cluster, atau kelompok keamanan individu untuk masing-masing.

Untuk kedua kasus, Anda perlu mengizinkan lalu lintas keluar TCP pada ElastiCache port dari sumber dan lalu lintas masuk pada port yang sama ke ElastiCache. Port default adalah 11211 untuk Memcached dan 6379 untuk Redis. Secara default, grup keamanan mengizinkan semua lalu lintas ke luar. Dalam kasus ini, hanya aturan masuk ke target grup keamanan yang diperlukan.

Untuk informasi selengkapnya, lihatPola akses untuk mengakses ElastiCache klaster di Amazon VPC.

ACL jaringan

Daftar Kontrol Akses (ACL) jaringan adalah aturan yang stateless. Lalu lintas harus diizinkan di kedua arah (masuk dan keluar) agar koneksi berhasil. ACL jaringan ditempatkan untuk subnet, bukan untuk sumber daya tertentu. Dimungkinkan untuk memiliki ACL yang sama ditugaskan ElastiCache dan sumber daya klien, terutama jika keduanya berada di subnet yang sama.

Secara default, ACL jaringan mengizinkan semua lalu lintas. Namun, dimungkinkan untuk menyesuaikan ACL menjadi menolak atau mengizinkan lalu lintas. Selain itu, evaluasi aturan ACL adalah berurutan, yang berarti bahwa aturan dengan nomor terendah yang cocok dengan lalu lintas yang akan mengizinkan atau menolak lalu lintas itu. Konfigurasi minimum untuk mengizinkan lalu lintas Redis adalah:

ACL Jaringan sisi klien:

  • Aturan Masuk:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: Aturan TCP Kustom;

  • Protokol: TCP

  • Rentang Port: 1024-65535

  • Sumber: 0.0.0.0/0 (atau buat aturan tersendiri untuk ElastiCache subnet cluster)

  • Izinkan/Tolak: Izinkan

  • Aturan keluar:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: Aturan TCP Kustom;

  • Protokol: TCP

  • Rentang Port: 6379

  • Sumber: 0.0.0/0 (atau ElastiCache subnet cluster. Ingat bahwa menggunakan IP spesifik dapat menimbulkan masalah jika melakukan failover atau penskalaan klaster)

  • Izinkan/Tolak: Izinkan

ElastiCache ACL Jaringan:

  • Aturan Masuk:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: Aturan TCP Kustom;

  • Protokol: TCP

  • Rentang Port: 6379

  • Sumber: 0.0.0.0/0 (atau buat aturan tersendiri untuk ElastiCache subnet cluster)

  • Izinkan/Tolak: Izinkan

  • Aturan keluar:

  • Nomor aturan: sebaiknya lebih rendah dari semua aturan menolak;

  • Jenis: Aturan TCP Kustom;

  • Protokol: TCP

  • Rentang Port: 1024-65535

  • Sumber: 0.0.0/0 (atau ElastiCache subnet cluster. Ingat bahwa menggunakan IP spesifik dapat menimbulkan masalah jika melakukan failover atau penskalaan klaster)

  • Izinkan/Tolak: Izinkan

Untuk informasi lain, lihat ACL Jaringan.

Tabel rute

Sama seperti ACL Jaringan, setiap subnet dapat memiliki tabel rute yang berbeda. Jika klien dan ElastiCache klaster berada di subnet yang berbeda, pastikan bahwa rute tabel keduanya memungkinkan keduanya saling menjangkau satu sama lain.

Lingkungan yang lebih kompleks, yang melibatkan beberapa VPC, perutean dinamis, atau firewall jaringan, mungkin menjadi sulit untuk melakukan pemecahan masalah. Lihat Validasi konektivitas jaringan untuk mengonfirmasi bahwa pengaturan jaringan Anda sesuai.

Resolusi nama DNS

ElastiCache menyediakan titik akhir layanan yang berdasarkan nama DNS. Titik akhir yang tersedia adalah Configuration, Primary, Reader, dan titik akhir Node. Untuk informasi lain, lihat Menemukan Titik Akhir Koneksi.

Dalam hal failover atau perubahan klaster, alamat yang terkait dengan nama titik akhir mungkin berubah dan akan diperbarui secara otomatis.

Pengaturan DNS khusus (yaitu, tidak menggunakan layanan DNS VPC) mungkin tidak menyadari ElastiCachenama DNS -disediakan. Pastikan bahwa sistem Anda dapat berhasil menyelesaikan ElastiCache endpoint menggunakan alat sistem sepertidig(seperti yang ditunjukkan berikut) ataunslookup.

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

Anda juga dapat memaksakan resolusi nama melalui layanan DNS VPC:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Mengidentifikasi masalah dengan diagnostik sisi server

CloudWatch metrik dan informasi run-time dari ElastiCache mesin adalah sumber atau informasi yang umum untuk mengidentifikasi potensi sumber masalah koneksi. Analisis yang baik biasanya dimulai dengan item berikut:

  • Penggunaan CPU: Redis adalah aplikasi multi-thread. Akan tetapi, pelaksanaan dari setiap perintah terjadi dalam satu thread tunggal (utama). Untuk alasan ini, ElastiCache menyediakan metrikCPUUtilizationdanEngineCPUUtilization.EngineCPUUtilizationmenyediakan pemanfaatan CPU yang didedikasikan untuk proses Redis, danCPUUtilizationpenggunaan di semua vCPUs. Simpul dengan lebih dari satu vCPU biasanya memiliki nilai yang berbeda untuk CPUUtilization dan EngineCPUUtilization, di mana nilai yang kedua umumnya lebih tinggi. EngineCPUUtilization yang tinggi dapat disebabkan oleh peningkatan jumlah permintaan atau operasi kompleks yang membutuhkan waktu CPU yang besar untuk bekerja. Anda dapat mengidentifikasi keduanya dengan berikut ini:

    • Jumlah permintaan yang meningkat: Periksa peningkatan pada metrik lain yang cocokEngineCPUUtilizationpola. Metrik yang berguna adalah:

      • CacheHits dan CacheMisses: jumlah permintaan berhasil atau permintaan yang tidak menemukan item yang valid di dalam cache. Jika rasio dari yang meleset lebih tinggi dibandingkan yang berhasil, maka aplikasi memboroskan waktu dan sumber daya dengan permintaan yang tidak membuahkan hasil.

      • SetTypeCmds dan GetTypeCmds: Metrik ini berkorelasi denganEngineCPUUtilizationdapat membantu untuk memahami apakah beban secara signifikan lebih tinggi untuk permintaan tulis, diukur denganSetTypeCmds, atau membaca, diukur denganGetTypeCmds. Jika yang lebih banyak adalah beban baca, maka menggunakan beberapa replika baca dapat menyeimbangkan permintaan di beberapa simpul sehingga simpul primer dapat melayani permintaan tulis saja. Pada klaster dengan mode pengaktifan klaster, penggunaan replika baca dapat dilakukan dengan membuat konfigurasi koneksi tambahan dalam aplikasi menggunakan ElastiCache endpoint pembaca. Untuk informasi lain, lihat Menemukan Titik Akhir Koneksi. Operasi baca harus diserahkan ke koneksi tambahan ini. Operasi tulis akan dilakukan melalui titik akhir primer biasa. Pada pengaktifan mode klaster, sebaiknya menggunakan pustaka yang mendukung replika baca secara asli. Dengan tanda yang tepat, pustaka akan dapat secara otomatis menemukan topologi klaster, simpul replika, mengaktifkan operasi baca melalui perintah Redis READONLY, dan mengirimkan permintaan baca ke replika.

    • Jumlah koneksi yang meningkat:

      • CurrConnections dan NewConnections: CurrConnection adalah jumlah koneksi yang dibuat pada saat pengumpulan titik data, sementara NewConnections menunjukkan jumlah koneksi yang dibuat pada periode itu.

        Membuat dan menangani koneksi menyebabkan overhead CPU yang cukup besar. Selain itu, proses jabat tangan tiga arah TCP yang diperlukan untuk membuat sambungan baru akan berdampak secara negatif pada waktu respons secara keseluruhan.

        Sesi ElastiCache simpul dengan ribuanNewConnectionsper menit menunjukkan bahwa koneksi dibuat dan digunakan hanya oleh beberapa perintah, yang tidak optimal. Menjaga koneksi selalu tersedia dan menggunakan kembali koneksi itu untuk operasi baru adalah praktik terbaik. Hal ini dimungkinkan jika aplikasi klien mendukung dan menerapkan dengan baik pengumpulan koneksi atau koneksi yang persisten. Dengan pengumpulan koneksi, angka currConnections tidak akan memiliki variasi besar, dan NewConnections seharusnya menjadi serendah mungkin. Redis memberikan kinerja yang optimal dengan currConnections yang kecil. Menjaga currConnection dalam kelompok puluhan atau ratusan meminimalkan penggunaan sumber daya untuk mendukung koneksi tersendiri seperti buffer klien dan siklus CPU untuk melayani koneksi.

    • Throughput jaringan:

      • Tentukan bandwidth: ElastiCache simpul memiliki bandwith jaringan yang sebanding dengan ukuran simpul. Karena aplikasi memiliki karakteristik yang berbeda, hasilnya dapat bervariasi sesuai dengan beban kerja. Sebagai contoh, aplikasi dengan permintaan kecil dengan laju yang tinggi cenderung menyebabkan penggunaan CPU lebih besar daripada throughput jaringan sementara kunci yang lebih besar akan menyebabkan pemanfaatan jaringan yang lebih tinggi. Untuk alasan itu, sebaiknya menguji simpul dengan beban kerja yang sebenarnya untuk pemahaman yang lebih baik mengenai batasan.

        Mensimulasi beban dari aplikasi akan memberikan hasil yang lebih akurat. Akan tetapi, alat tolok ukur dapat memberikan gambaran yang baik tentang batasan.

      • Untuk kasus di mana permintaan didominasi oleh proses baca, menggunakan replika untuk operasi baca akan mengurangi beban pada simpul primer. Jika kasus penggunaan didominasi proses tulis, digunakannya banyak replika akan memperkuat penggunaan jaringan. Untuk setiap byte yang ditulis ke simpul primer, N byte akan dikirim ke replika, di mana N adalah jumlah replika. Praktik terbaik untuk menulis beban kerja intensif menggunakan ElastiCache untuk Redis dengan pengaktifan mode klaster sehingga proses tulis dapat diseimbangkan di seluruh serpihan, atau ditingkatkan skalanya menjadi jenis simpul dengan lebih banyak kemampuan jaringan.

      • Parameter CloudWatchmetrics NetworkBytesIndanNetworkBytesOutmemberikan jumlah data yang masuk ke atau meninggalkan node, masing-masing.ReplicationBytesadalah lalu lintas yang didedikasikan untuk replikasi data.

      Untuk informasi selengkapnya, lihat Batas terkait jaringan.

    • Perintah Kompleks: Perintah Redis dilayani pada thread tunggal, yang berarti bahwa permintaan dilayani secara berurutan. Perintah tunggal yang lambat dapat mempengaruhi permintaan lain dan koneksi, yang berpuncak pada terjadinya waktu habis. Penggunaan perintah yang bertindak pada beberapa nilai, kunci, atau jenis data harus dilakukan dengan hati-hati. Koneksi dapat diblokir atau dihentikan tergantung pada jumlah parameter, atau ukuran nilai input atau outputnya.

      Contoh yang terkenal buruk adalah perintah KEYS. Perintah ini menyapu seluruh keyspace untuk mencari pola tertentu dan memblokir pelaksanaan dari perintah lain selama pelaksanaannya. Redis menggunakan notasi “Big O” untuk menggambarkan kompleksitas dari perintahnya.

      Perintah keys memiliki O(N) kali kompleksitas, N menjadi jumlah kunci dalam basis data. Oleh karena itu, semakin besar jumlah kunci, semakin lambat perintahnya.KEYSdapat menyebabkan masalah dengan cara yang berbeda: Jika tidak ada pola pencarian yang digunakan, perintah akan mengembalikan semua nama kunci yang tersedia. Dalam basis data dengan ribuan atau jutaan item, output yang besar akan tercipta dan membanjiri buffer jaringan.

      Jika pola pencarian digunakan, hanya kunci yang cocok dengan pola yang akan dikembalikan ke klien. Namun, mesin masih akan menyapu ke seluruh keyspace untuk mencarinya, dan waktu untuk menyelesaikan perintah akan sama.

      Alternatif untuk KEYS adalah perintah SCAN. Perintah ini melakukan iteratesi atas keyspace dan membatasi iterasi dalam jumlah tertentu dari item, menghindari pemblokiran yang berkepanjangan pada mesin.

      Scan memiliki parameter COUNT, digunakan untuk mengatur ukuran dari blok iterasi. Nilai defaultnya adalah 10 (10 item per iterasi).

      Tergantung pada jumlah item dalam basis data, blok dengan nilai COUNT yang kecil akan membutuhkan lebih banyak iterasi untuk menyelesaikan perintah scan penuh, dan nilai yang lebih besar ini akan membuat mesin sibuk lebih lama di setiap iterasi. Sementara nilai count yang kecil akan membuat SCAN lebih lambat pada basis data yang besar, nilai yang lebih besar dapat menyebabkan masalah yang sama seperti disebutkan untuk KEYS.

      Sebagai contoh, menjalankan perintah SCAN dengan nilai hitungan sebesar 10 akan membutuhkan 100.000 pengulangan pada basis data dengan 1 juta kunci. Jika waktu bolak-balik jaringan rata-rata adalah 0,5 milidetik, sekitar 50.000 milidetik (50 detik) akan dihabiskan untuk mengirimkan permintaan ini.

      Di sisi lain, jika nilai count adalah 100,0000, iterasi tunggal akan diperlukan dan hanya 0,5 milidetik yang akan dihabiskan untuk mengirimnya. Akan tetapi, mesin akan sepenuhnya terblokir untuk operasi lain sampai perintah itu selesai menyapu semua keyspace.

      Selain KEYS, beberapa perintah lain berpotensi membahayakan jika tidak digunakan dengan benar. Untuk melihat daftar semua perintah dan kompleksitas waktunya masing-masing, kunjungi https://redis.io/commands.

      Contoh potensi masalah:

      • Skrip Lua: Redis menyediakan interpreter Lua tertanam, yang memungkinkan pelaksanaan skrip di sisi server. Skrip Lua pada Redis dijalankan di tingkat mesin dan bersifat atom menurut definisi, yang berarti bahwa tidak ada perintah atau skrip lain akan diizinkan untuk bekerja sementara skrip itu dijalankan. Skrip Lua menyediakan kemungkinan untuk menjalankan beberapa perintah, algoritma pengambilan keputusan, penguraian data, dan lain-lain secara langsung pada mesin Redis. Meskipun sifat atom dari skrip dan kemungkinan melepaskan aplikasi cukup menarik, skrip harus digunakan dengan hati-hati dan untuk operasi yang kecil. Pada ElastiCache, waktu eksekusi dari skrip Lua dibatasi 5 detik. Skrip yang belum ditulis ke keyspace akan secara otomatis dihentikan setelah periode 5 detik. Untuk menghindari kerusakan dan inkonsistensi data, simpul akan melakukan failover jika pelaksanaan skrip belum selesai dalam 5 detik dan tetap menjalankan proses tulis apapun selama pelaksanaan skrip. Perintah transactions adalah alternatif untuk menjamin konsistensi dari perubahan beberapa kunci yang terkait di Redis. Transaksi memungkinkan eksekusi dari suatu blok perintah, memperhatikan perubahan pada kunci yang telah ada. Jika salah satu kunci yang diperhatikan berubah sebelum selesainya transaksi, maka semua perubahan akan dibuang.

      • Penghapusan massal item: ParameterDELperintah menerima beberapa parameter, yang merupakan nama kunci yang akan dihapus. Operasi penghapusan bersifat sinkron dan akan mengambil waktu CPU yang signifikan jika daftar parameter besar, atau berisi daftar yang panjang, set, set berurutan, atau hash yang besar (struktur data memegang beberapa sub-item). Dengan kata lain, bahkan penghapusan satu kunci pun dapat memakan waktu lama jika kunci itu memiliki banyak elemen. Alternatif untuk DEL adalah UNLINK, yang merupakan perintah asinkron yang tersedia sejak Redis 4. UNLINK seharusnya lebih dipilih daripada DEL jika dimungkinkan. Dimulai pada ElastiCache untuk Redis 6x,lazyfree-lazy-user-delparameter membuatDELperintah berperilaku sepertiUNLINKsaat diaktifkan. Untuk informasi selengkapnya, lihatPerubahan Parameter Redis 6.0.

      • Perintah yang bekerja pada beberapa kunci: DEL disebutkan sebelumnya sebagai perintah yang menerima beberapa argumen dan waktu pelaksanaannya akan berbanding lurus dengan itu. Namun, Redis menyediakan lebih banyak perintah yang bekerja dengan cara yang sama. Sebagai contoh, MSET dan MGET memungkinkan penyisipan atau pengambilan beberapa kunci String sekaligus. Penggunaannya mungkin bermanfaat untuk mengurangi latensi jaringan yang terjadi pada beberapa perintah tersendiri SET atau GET. Akan tetapi, daftar parameter yang panjang akan mempengaruhi penggunaan CPU.

        Sementara pemanfaatan CPU sendiri bukan penyebab untuk masalah konektivitas, menghabiskan terlalu banyak waktu untuk memproses satu atau beberapa perintah atas beberapa kunci dapat menyebabkan kegagalan permintaan lain dan meningkatkan pemanfaatan CPU secara keseluruhan.

        Jumlah kunci dan ukurannya akan mempengaruhi kompleksitas perintah dan karena itu waktu penyelesaian.

        Contoh lain dari perintah yang dapat bertindak atas beberapa kunci:HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER atau ZINTERSTORE.

      • Perintah yang bertindak atas beberapa tipe data: Redis juga menyediakan perintah yang bertindak atas satu atau beberapa kunci, terlepas dari jenis data mereka. ElastiCache untuk Redis menyediakan metrikKeyBasedCmdsuntuk memantau perintah tersebut. Metrik ini menjumlahkan eksekusi dari perintah berikut pada periode yang dipilih:

        • Kompleksitas O(N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N) untuk mengeklaim kembali memori. Namun tugas mengeklaim kembali memori itu terjadi di thread yang terpisah dan tidak memblokir mesin

        • Waktu kompleksitas yang berbeda akan tergantung pada jenis data:

          • DEL

          • DUMP

          • RENAME dianggap perintah dengan kompleksitas O(1), tetapi menjalankan DEL secara internal. Waktu pelaksanaan akan bervariasi tergantung pada ukuran kunci yang diganti namanya.

          • RENAMENX

          • RESTORE

          • SORT

        • Hash besar: Hash adalah jenis data yang memungkinkan satu kunci dengan beberapa sub-item nilai kunci. Setiap hash dapat menyimpan 4.294.967.295 item dan operasi pada hash yang besar dapat menjadi mahal. Sama dengan KEYS, hash mempunyai perintah HKEYS dengan kompleksitas waktu O(N), N adalah jumlah item dalam hash. HSCAN seharusnya lebih dipilih dibandingkan HKEYS untuk menghindari perintah yang berjalan lama. HDEL, HGETALL, HMGET, HMSET dan HVALS adalah perintah yang harus digunakan dengan hati-hati pada hash besar.

      • Struktur data besar lainnya: Selain hash, struktur data lainnya dapat memakan waktu CPU. Sets, Lists, Sorted Sets, dan Hyperloglogs juga dapat memakan waktu yang lama untuk dimanipulasi tergantung pada ukuran dan perintah yang digunakan. Untuk informasi lain tentang perintah tersebut, lihathttps://redis.io/commands.

Validasi konektivitas jaringan

Setelah meninjau konfigurasi jaringan yang berkaitan dengan resolusi DNS, grup keamanan, ACL jaringan, dan tabel rute, konektivitas dapat divalidasi dengan VPC Reachability Analyzer dan alat sistem.

Reachability Analyzer akan menguji konektivitas jaringan dan mengonfirmasi jika semua persyaratan dan izin terpenuhi. Untuk uji di bawah ini Anda akan memerlukan ENI ID (Identifikasi Antarmuka Jaringan Elastis) dari salah satu ElastiCache node tersedia di VPC Anda. Anda dapat menemukannya dengan melakukan hal berikut:

  1. Kunjungi https://console.aws.amazon.com/ec2/v2/home?#NIC:

  2. Saring daftar antarmuka dengan nama klaster Elasticache Anda atau alamat IP yang didapat dari validasi DNS sebelumnya.

  3. Tuliskan atau simpan ENI ID. Jika beberapa antarmuka ditampilkan, tinjau deskripsi untuk mengonfirmasi bahwa antarmuka tersebut termasuk dalam hak ElastiCache klaster dan pilih salah satu dari mereka.

  4. Lanjutkan ke langkah berikutnya.

  5. Buat jalur analisis dihttps://console.aws.amazon.com/vpc/home #ReachabilityAnalyzerdan pilih opsi berikut:

    • Jenis Sumber: Memiilihcontohjika ElastiCache klien berjalan di instans Amazon EC2 atauAntarmuka Jaringanjika menggunakan layanan lain, sepertiAWS FargateAmazon ECS dengan jaringan awsvpc,AWS Lambda, dll), dan ID sumber daya masing-masing (contoh EC2 atau ENI ID);

    • Jenis tujuan: MemiilihAntarmuka Jaringandan pilihENI Elastisdari daftar.

    • Port tujuan: tentukan 6379 untuk ElastiCache untuk Redis atau 11211 untuk ElastiCache untuk Memcached. Itu adalah port yang didefinisikan dengan konfigurasi default dan contoh ini mengasumsikan bahwa port tersebut tidak berubah.

    • Protokol: TCP

Buat jalur analisis dan tunggu beberapa saat untuk hasilnya. Jika status tidak terjangkau, buka detail analisis dan tinjau Penjelejah analisis untuk detail di mana permintaan diblokir.

Jika tes penjangkauan sudah lulus, lanjutkan ke verifikasi di tingkat OS.

Untuk memvalidasi konektivitas TCP pada ElastiCache Port layanan: Di Amazon Linux,Npingtersedia dalam paketnmapdan dapat menguji konektivitas TCP pada ElastiCache port, serta menyediakan waktu pulang-pergi jaringan untuk membangun koneksi. Gunakan ini untuk memvalidasi konektivitas jaringan dan latensi saat ini ElastiCache klaster, seperti yang ditunjukkan berikut: 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

Secara default, nping mengirimkan 5 paket penyelidikan dengan waktu tunda 1 detik di antara paket itu. Anda dapat menggunakan opsi “-c” untuk menambah jumlah paket penyelidikan dan “—delay “ untuk mengubah waktu untuk mengirim pengujian baru.

Jika pengujian dengan nping gagal dan pengujian VPC Reachability Analyzer lulus, mintalah administrator sistem Anda untuk meninjau kemungkinan aturan firewall berbasis Host, aturan perutean asimetris, atau pembatasan lain yang dimungkinkan di tingkat sistem operasi.

Pada ElastiCache konsol, periksa apakahEnkripsi in-transitdiaktifkan di ElastiCache rincian klaster. Jika enkripsi in-transit diaktifkan, lakukan konfirmasi jika sesi TLS dapat dibuat dengan perintah berikut:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Output yang panjang akan keluar jika koneksi dan negosiasi TLS berhasil. Periksa kode yang dihasilkan yang terdapat di baris terakhir, nilainya harus 0 (ok). Jika openssl menghasilkan sesuatu yang berbeda, periksa alasan untuk kesalahan itu di https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS.

Jika semua pengujian infrastruktur dan sistem operasi sudah lulus tetapi aplikasi Anda masih tidak dapat terhubung ElastiCache, periksa apakah konfigurasi aplikasi sesuai dengan ElastiCache pengaturan. Kesalahan yang umum adalah:

  • Aplikasi Anda tidak mendukung ElastiCache Mode klaster, dan ElastiCache memiliki pengaktifan mode klaster;

  • Aplikasi Anda tidak mendukung TLS/SSL, dan ElastiCache mengaktifkan enkripsi in-transit;

  • Aplikasi mendukung TLS/SSL tetapi tidak memiliki tanda konfigurasi atau otoritas sertifikasi tepercaya yang tepat;

Batas terkait jaringan

  • Jumlah maksimum koneksi: Ada batas keras untuk koneksi secara serentak. MASING-MASING ElastiCache simpul memungkinkan hingga 65.000 koneksi secara serentak di seluruh klien. Batas ini dapat dipantau melalui metrik CurrConnections di CloudWatch. Namun, klien juga memiliki batas untuk koneksi keluar. Pada Linux, periksa rentang port ephemeral yang diizinkan dengan perintah:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    Pada contoh sebelumnya, 28231 koneksi akan diizinkan dari sumber yang sama, ke IP tujuan yang sama (ElastiCache node) dan port. Perintah berikut menunjukkan jumlah koneksi yang telah ada untuk simpul Elasticache tertentu (IP 1.2.3.4):

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Jika jumlah itu terlalu tinggi, sistem Anda mungkin menjadi kelebihan beban mencoba untuk memproses permintaan koneksi. Sebaiknya mempertimbangkan menerapkan teknik seperti pengumpulan koneksi atau koneksi persisten untuk menangani koneksi itu lebih baik. Jika memungkinkan, lakukan konfigurasi kumpulan koneksi untuk membatasi jumlah maksimum koneksi hanya beberapa ratus. Juga, logika back-off untuk menangani masalah waktu habis atau pengecualian koneksi lain juga dianjurkan untuk menghindari masalah koneksi yang putus sambung dengan cepat.

  • Batas lalu lintas jaringan: Periksa hal berikutCloudWatch metrik untuk Redisuntuk mengidentifikasi kemungkinan batas jaringan yang terkena pada ElastiCache simpul:

    • NetworkBandwidthInAllowanceExceeded / NetworkBandwidthOutAllowanceExceeded: Paket jaringan yang ditunda karena throughput melebihi batas agregasi bandwidth.

      Penting untuk dicatat bahwa setiap byte yang ditulis ke simpul primer akan direplikasi ke N replika, di mana N adalah jumlah replika. Klaster dengan jenis simpul kecil, beberapa replika, dan permintaan tulis intensif mungkin tidak mampu mengatasi backlog replikasi. Untuk kasus seperti itu, praktik terbaik adalah meningkatkan skala (mengubah jenis node), menskalakan keluar (menambahkan serpihan dalam klaster dengan pengaktifan mode klaster), mengurangi jumlah replika, atau meminimalkan jumlah proses tulis.

    • NetworkConntrackAllowanceExceeded: Paket yang ditunda karena telah terlampauinya jumlah maksimum koneksi yang dilacak di seluruh grup keamanan yang ditetapkan ke simpul. Koneksi baru kemungkinan akan gagal selama periode ini.

    • NetworkPackets PerSecondAllowanceExceeded: Jumlah maksimum paket per detik terlampaui. Beban kerja berdasarkan laju yang tinggi dari permintaan yang sangat kecil dapat mencapai batas ini sebelum bandwidth mencapai maksimum.

    Metrik di atas adalah cara ideal untuk mengonfirmasi simpul yang mencapai batas jaringannya. Namun, batas juga dapat diidentifikasi dengan bentuk plato pada metrik jaringan.

    Jika bentuk plato diamati dalam waktu yang lama, mungkin akan diikuti oleh ketertinggalan replikasi, peningkatan byte yang digunakan untuk cache, penurunan pada memori yang dapat dibebaskan, serta swap dan penggunaan CPU yang tinggi. Instans Amazon EC2 juga memiliki batasan jaringan yang dapat dilacakMetrik driver ENA. Instans Linux dengan dukungan jaringan yang ditingkatkan dan penggerak ENA 2.2.10 atau yang lebih baru dapat meninjau penghitung batas dengan perintah:

    # ethtool -S eth0 | grep "allowance_exceeded"

Penggunaan CPU

Metrik penggunaan CPU adalah titik awal penyelidikan, dan item berikut dapat membantu untuk mempersempit kemungkinan masalah pada ElastiCache sisi:

  • Redis SlowLogs: Parameter ElastiCache konfigurasi default mempertahankan 128 perintah terakhir yang membutuhkan 10 milidetik untuk diselesaikan. Sejarah perintah lambat disimpan selama waktu aktif mesin dan akan hilang jika terjadi kegagalan atau mulai ulang. Jika daftar mencapai 128 entri, maka peristiwa lama akan dihapus untuk memberikan tempat untuk peristiwa baru. Ukuran dari daftar peristiwa lambat dan waktu pelaksanaan yang dianggap lambat dapat diubah melalui parameter slowlog-max-len dan slowlog-log-slower-than di dalam grup parameter khusus. Daftar slowlogs dapat diambil dengan menjalankan SLOWLOG GET 128 pada mesin, 128 adalah 128 perintah lambat terakhir yang dilaporkan. Setiap entri memiliki bidang berikut:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    Peristiwa di atas terjadi pada tanggal 26 Desember pukul 19:26:07 UTC, membutuhkan 4,8 detik (4,823ms) untuk diselesaikan dan disebabkan oleh perintah KEYS yang diminta dari klien 1.2.3.4.

    Di Linux, stempel waktu dapat dikonversi dengan perintah tanggal:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Pada Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    Atau pada Windows dengan PowerShell:

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Banyak perintah lambat dalam waktu singkat (menit yang sama atau kurang) menjadi hal yang dikhawatirkan. Tinjau sifat dari perintah dan bagaimana perintah itu dapat dioptimalkan (lihat contoh sebelumnya). Jika perintah dengan kompleksitas waktu O(1) sering dilaporkan, periksa faktor lain yang menyebabkan penggunaan CPU tinggi yang disebutkan sebelumnya.

  • Metrik latensi: ElastiCache untuk Redis menyediakan CloudWatch metrik untuk memantau latensi rata-rata untuk kelas perintah yang berbeda. Titik data dihitung dengan membagi jumlah pelaksanaan perintah dalam kategori dengan total waktu pelaksanaan pada periode tersebut. Penting untuk dipahami bahwa hasil metrik latensi merupakan kumpulan dari beberapa perintah. Satu perintah dapat menyebabkan hasil tidak terduga, seperti waktu habis, tanpa dampak signifikan pada metrik. Untuk kasus seperti ini, peristiwa slowlog akan menjadi sumber informasi yang lebih akurat. Daftar berikut berisi metrik latensi yang tersedia dan perintah terkait yang mempengaruhinya.

    • EvalBasedCmdsLatency: terkait dengan perintah Skrip Lua,eval,evalsha;

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: Perintah baca, terlepas dari jenis data;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: Perintah yang dapat bertindak berdasarkan tipe data yang berbeda:dump,exists,keys,object,pttl,randomkey,ttl,type,del,expire,expireat,move,persist,pexpire,pexpireat,rename,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, llen, llen, brpop, brpop, brpop, brpop, lpush, lpush, lpush, lpush, lpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush, rpush,

    • PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: Perintah tulis, terlepas dari jenis data;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Perintah waktu aktif Redis:

    • Commandstats info: Menyediakan daftar perintah yang dilaksanakan sejak mesin Redis dimulai, jumlah eksekusi kumulatifnya, total waktu eksekusi, dan rata-rata waktu pelaksanaan per perintah;

    • Daftar klien: Menyediakan daftar dari klien yang saat ini tersambung dan informasi yang relevan seperti penggunaan buffer, perintah yang dilaksanakan terakhir, dll;

  • Backup dan replikasi: ElastiCache untuk versi Redis sebelumnya dari 2.8.22 gunakan proses bercabang untuk membuat backup dan proses sinkronisasi penuh dengan replika. Metode ini mungkin menyebabkan overhead memori yang besar untuk kasus penggunaan proses tulis intensif.

    Dimulai dengan Elasticache Redis 2.8.22, AWS memperkenalkan metode backup dan replikasi dengan proses bercabang. Metode yang baru dapat menunda proses tulis untuk mencegah kegagalan. Kedua metode dapat menyebabkan periode pemanfaatan CPU yang lebih tinggi, yang menyebabkan waktu respons lebih tinggi dan akibatnya menyebabkan klien mengalami waktu habis selama melaksanakan perintah. Selalu periksa apakah kegagalan klien terjadi selama jendela backup atau metrik SaveInProgress bernilai 1 pada periode tersebut. Sebaiknya menjadwalkan jendela backup untuk periode pemanfaatan yang rendah untuk meminimalkan kemungkinan masalah dengan klien atau kegagalan proses backup.

Koneksi yang dihentikan dari sisi server

Bawaan ElastiCache untuk konfigurasi Redis menjaga koneksi klien tetap tersedia tanpa batas waktu. Akan tetapi, dalam beberapa kasus penghentian koneksi mungkin diinginkan. Misalnya:

  • Bug dalam aplikasi klien dapat menyebabkan koneksi dilupakan dan tetap tersambung dengan keadaan tidak dipakai. Ini disebut “kebocoran koneksi “ dan konsekuensinya adalah peningkatan yang tetap pada jumlah koneksi tersambung yang diamati pada metrik CurrConnections. Perilaku ini dapat mengakibatkan saturasi pada klien atau ElastiCache sisi. Jika perbaikan langsung tidak dimungkinkan dari sisi klien, beberapa administrator menetapkan nilai” waktu habis “di dalamnya ElastiCache Grup parameter. Waktu habis adalah waktu dalam detik yang diizinkan untuk koneksi diam/menganggur untuk bertahan. Jika klien tidak mengirimkan permintaan apapun dalam periode itu, mesin Redis akan mengakhiri koneksi itu segera setelah koneksi itu mencapai nilai waktu habis. Nilai waktu habis yang kecil dapat mengakibatkan pemutusan koneksi yang tidak perlu dan klien akan perlu menangani ini dengan tepat dan menyambungkan kembali, yang menyebabkan penundaan.

  • Memori yang digunakan untuk menyimpan kunci dibagikan dengan buffer klien. Klien lambat dengan permintaan atau tanggapan besar mungkin menuntut sejumlah besar memori untuk menangani buffer-nya. Bawaan ElastiCache untuk konfigurasi Redis tidak membatasi ukuran buffer keluaran dari klien biasa. Jika batas maxmemory tercapai, mesin akan mencoba untuk mengeluarkan item untuk memenuhi penggunaan buffer. Dalam kondisi memori rendah yang ekstrim, ElastiCache untuk Redis mungkin memilih untuk memutuskan koneksi klien yang mengonsumsi buffer keluaran klien yang besar untuk membebaskan memori dan mempertahankan kesehatan klaster.

    Dimungkinkan untuk membatasi ukuran buffer klien dengan konfigurasi khusus dan klien yang mencapai batas ini akan terputus. Namun, klien harus dapat menangani pemutusan yang tidak terduga. Parameter untuk menangani ukuran buffer untuk klien biasa adalah sebagai berikut:

    • client-query-buffer-limit: Ukuran maksimum dari permintaan input tunggal;

    • client-output-buffer-limit-normal-soft-limit: Batas lunak untuk koneksi klien. Sambungan akan dihentikan jika tetap berada di atas batas lunak selama lebih dari waktu dalam detik yang didefinisikan client-output-buffer-limit-normal-soft-seconds atau jika menyentuh batas yang sulit;

    • client-output-buffer-limit-normal-soft-seconds: Waktu yang diizinkan untuk koneksi melebihi client-output-buffer-limit-normal-soft-limit;

    • client-output-buffer-limit-normal-hard-limit: Koneksi yang mencapai batas ini akan segera dihentikan.

    Selain buffer klien biasa, pilihan berikut mengontrol buffer untuk simpul replika dan klien Pub/Sub (Publikasi/Berlangganan):

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Pemecahan masalah sisi klien untuk instans Amazon EC2

Beban dan tingkat respons pada sisi klien juga dapat mempengaruhi permintaan ke ElastiCache. Batas dari instans EC2 dan sistem operasi harus ditinjau dengan hati-hati sambil melakukan pemecahan masalah konektivitas yang putus-putus atau masalah waktu habis. Beberapa poin penting untuk diamati:

  • CPU:

    • Penggunaan CPU instans EC2: Pastikan CPU belum jenuh atau mendekati 100 persen. Analisis historis dapat dilakukan melalui CloudWatch, namun perlu diingat bahwa titik data secara granular adalah baik 1 menit (dengan pengaktifan pemantauan terperinci) atau 5 menit;

    • Jika menggunakan instans EC2 burstable, pastikan bahwa saldo kredit CPU belum habis. Informasi ini tersedia diCPUCreditBalance CloudWatch metrik.

    • Periode pendek penggunaan CPU yang tinggi dapat menyebabkan waktu habis tanpa mencerminkan 100 persen pemanfaatan pada CloudWatch. Kasus seperti itu memerlukan pemantauan waktu nyata dengan peralatan sistem operasi seperti top, ps, dan mpstat.

  • Jaringan

    • Periksa apakah throughput Jaringan berada di bawah nilai yang dapat diterima sesuai dengan kemampuan instans. Untuk informasi lain, lihat Jenis Instans Amazon EC2

    • Pada instans dengan enapenggerak Jaringan yang Ditingkatkan, periksa statistik ena untuk batas waktu habis atau batas yang terlampaui. Statistik berikut berguna untuk mengonfirmasi kejenuhan batas jaringan:

      • bw_in_allowance_exceeded / bw_out_allowance_exceeded: jumlah paket yang ditunda karena kelebihan throughput masuk atau keluar;

      • conntrack_allowance_exceeded: jumlah paket yang tidak diteruskan karena batas pelacakan koneksi dari grup keamanan. Koneksi baru akan gagal saat batas ini jenuh;

      • linklocal_allowance_exceeded: jumlah paket yang tidak diteruskan karena permintaan berlebihan untuk metadata dari instans, NTP melalui DNS VPC. Batasnya adalah 1024 paket per detik untuk semua layanan;

      • pps_allowance_exceeded: jumlah paket yang tidak diteruskan karena rasio paket per detik yang berlebihan. Batas PPS dapat dipukul ketika lalu lintas jaringan terdiri dari ribuan atau jutaan permintaan yang sangat kecil per detik. ElastiCache lalu lintas dapat dioptimalkan untuk membuat lebih baik menggunakan paket jaringan melalui pipa atau perintah yang melakukan beberapa operasi sekaligus sepertiMGETbukannyaGET.

Membedah waktu yang dibutuhkan untuk menyelesaikan satu permintaan tunggal

  • Di jaringan:TcpdumpdanWireshark(tshark pada baris perintah) adalah alat yang praktis untuk memahami lama waktu yang dibutuhkan permintaan untuk bergerak melalui jaringan, mencapai ElastiCache mesin dan mendapatkan kembali. Contoh berikut menyorot satu permintaan tunggal yang dibuat dengan perintah berikut: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    Sejajar dengan perintah di atas, tcpdump dijalankan dan menghasilkan:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    Dari keluaran di atas kita dapat mengonfirmasi bahwa jabat tangan tiga arah TCP diselesaikan dalam 222 mikrodetik (918091 - 917869) dan perintah ping diajukan dan dikembalikan dalam 173 mikrodetik (918295 - 918122).

    Dibutuhkan waktu 438 mikrodetik (918307 - 917869) mulai dari membuat permintaan hingga koneksi ditutup. Hasil tersebut akan memastikan bahwa waktu respons jaringan dan mesin adalah baik dan penyelidikan dapat berfokus pada komponen lainnya.

  • Pada sistem operasi: Strace dapat membantu mengidentifikasi kesenjangan waktu pada tingkat OS. Analisis aplikasi aktual akan jauh lebih luas dan dianjurkan menggunakan alat profil khusus untul aplikasi atau debugger. Contoh berikut hanya menunjukkan jika komponen sistem operasi dasar bekerja seperti yang diharapkan, jika tidak, penyelidikan lebih lanjut mungkin diperlukan. Menggunakan Redis yang sama, perintah PING dengan strace kita mendapatkan:

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    Pada contoh di atas, perintah membutuhkan waktu sekitar 54 milidetik untuk diselesaikan (752110 - 697712 = 54398 mikrodetik).

    Lama waktu yang signifikan, sekitar 20 ms, dibutuhkan untuk membuat instans nc dan melakukan resolusi nama (dari 697712 untuk 717890), setelah itu, waktu 2 ms diperlukan untuk membuat soket TCP (745659 untuk 747858), dan waktu 0,4 ms (747858 untuk 748330) dibutuhkan untuk mengirimkan dan menerima respons untuk permintaan.