Langkah pemecahan masalah tambahan - Amazon ElastiCache (Redis) OSS
Grup keamananACL jaringanTabel ruteResolusi 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.

Langkah pemecahan masalah tambahan

Item berikut harus diverifikasi saat memecahkan masalah konektivitas persisten dengan: ElastiCache

Grup keamanan

Grup Keamanan adalah firewall virtual yang melindungi ElastiCache klien Anda (instans EC2, AWS Lambda fungsi, wadah Amazon ECS, dll.) dan cache. ElastiCache Grup keamanan bersifat stateful, artinya bahwa setelah lalu lintas masuk atau keluar diizinkan, maka tanggapan untuk lalu lintas itu akan secara otomatis mendapatkan 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. Silakan merujuk ke bagian pemecahan masalah untuk bantuan tentang cara mengidentifikasi apakah batas telah tercapai pada klien atau ElastiCache sisi.

Anda dapat memiliki satu grup keamanan yang ditetapkan pada saat yang sama ke klien dan ElastiCache klaster, atau grup keamanan individual untuk masing-masing grup.

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

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

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 ke subnet, bukan untuk sumber daya tertentu. Dimungkinkan untuk memiliki ACL yang sama yang ditugaskan ke ElastiCache dan sumber daya klien, terutama jika mereka berada di subnet yang sama.

Secara default, ACL jaringan mengizinkan semua lalu lintas. Namun, dimungkinkan untuk menyesuaikan ACL agar 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 memungkinkan lalu lintas Redis OSS 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 individual untuk subnet cluster) ElastiCache

  • 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/0 (atau subnet cluster. ElastiCache Ingatlah bahwa menggunakan IP tertentu dapat menimbulkan masalah jika terjadi failover atau penskalaan cluster)

  • Izinkan/Tolak: Izinkan

ElastiCache Jaringan ACL:

  • 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 individual untuk subnet cluster) ElastiCache

  • 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/0 (atau subnet cluster. ElastiCache Ingatlah bahwa menggunakan IP tertentu dapat menimbulkan masalah jika terjadi failover atau penskalaan cluster)

  • Izinkan/Tolak: Izinkan

Untuk informasi selengkapnya, lihat ACL Jaringan.

Tabel rute

Sama seperti ACL Jaringan, setiap subnet dapat memiliki tabel rute yang berbeda. Jika klien dan ElastiCache cluster berada dalam subnet yang berbeda, pastikan bahwa tabel rute mereka memungkinkan mereka untuk mencapai satu sama lain.

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

Resolusi DNS

ElastiCache menyediakan titik akhir layanan berdasarkan nama DNS. Titik akhir yang tersedia adalah Configuration, Primary, Reader, dan titik akhir Node. Untuk informasi selengkapnya, 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 mengetahui nama DNS ElastiCache yang disediakan. Pastikan sistem Anda berhasil menyelesaikan ElastiCache titik akhir menggunakan alat sistem seperti dig (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 umum atau informasi untuk mengidentifikasi potensi sumber masalah koneksi. Analisis yang baik biasanya dimulai dengan item berikut:

  • Penggunaan CPU: Redis OSS adalah aplikasi multi-threaded. Namun, pelaksanaan dari setiap perintah terjadi dalam satu thread tunggal (utama). Untuk alasan ini, ElastiCache berikan metrik CPUUtilization danEngineCPUUtilization. EngineCPUUtilizationmenyediakan pemanfaatan CPU yang didedikasikan untuk proses Redis OSS, dan penggunaan CPUUtilization di semua vCPU. 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 diselesaikan. Anda dapat mengidentifikasi keduanya dengan berikut ini:

    • Peningkatan jumlah permintaan: Periksa peningkatan pada metrik lain yang cocok dengan pola EngineCPUUtilization. Metrik yang berguna adalah:

      • CacheHits dan CacheMisses: jumlah permintaan berhasil atau permintaan yang tidak menemukan item yang valid 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: Kedua metrik ini yang berhubungan dengan EngineCPUUtilization dapat membantu untuk memahami jika beban secara signifikan lebih tinggi untuk permintaan tulis, diukur oleh SetTypeCmds, atau lebih tinggi untuk permintaan baca, diukur oleh GetTypeCmds. 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. Dalam cluster yang dinonaktifkan mode cluster, penggunaan replika baca dapat dilakukan dengan membuat konfigurasi koneksi tambahan dalam aplikasi menggunakan endpoint pembaca. ElastiCache Untuk informasi selengkapnya, lihat Menemukan Titik Akhir Koneksi. Operasi baca harus dikirimkan ke koneksi tambahan ini. Operasi tulis akan dilakukan melalui titik akhir primer biasa. Pada mode klaster diaktifkan, sebaiknya menggunakan pustaka yang mendukung replika baca secara native. Dengan flag yang tepat, perpustakaan akan dapat secara otomatis menemukan topologi cluster, node replika, mengaktifkan operasi baca melalui perintah READONLY Redis OSS, 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 handshake tiga arah TCP yang diperlukan untuk membuat koneksi baru akan berdampak secara negatif pada waktu respons secara keseluruhan.

        Sebuah ElastiCache node dengan ribuan NewConnections per menit menunjukkan bahwa koneksi dibuat dan digunakan hanya dengan 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 pooling koneksi atau koneksi yang persisten. Dengan pooling koneksi, angka currConnections tidak akan memiliki variasi besar, dan NewConnections seharusnya menjadi serendah mungkin. Redis OSS memberikan kinerja optimal dengan sejumlah kecil CurrConnections. 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 node memiliki bandwidth jaringan yang sebanding dengan ukuran node. 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 pemanfaatan 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 tentang batasan.

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

      • Untuk kasus di mana permintaan didominasi oleh operasi baca, menggunakan replika untuk operasi baca akan mengurangi beban pada simpul primer. Jika kasus penggunaan didominasi operasi 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 adalah menggunakan ElastiCache (Redis OSS) dengan mode cluster yang diaktifkan sehingga penulisan dapat diseimbangkan di beberapa pecahan, atau ditingkatkan ke tipe node dengan lebih banyak kemampuan jaringan.

      • CloudWatchmetrics NetworkBytesInDan NetworkBytesOut memberikan jumlah data yang masuk atau keluar dari node, masing-masing. ReplicationBytesadalah lalu lintas yang didedikasikan untuk replikasi data.

      Untuk informasi selengkapnya, lihat Batas terkait jaringan.

    • Perintah kompleks: Perintah Redis OSS disajikan pada satu utas, yang berarti bahwa permintaan disajikan secara berurutan. Perintah tunggal yang lambat dapat memengaruhi 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 output-nya.

      Contoh yang terkenal buruk adalah perintah KEYS. Perintah ini menyapu seluruh ruang kunci untuk mencari pola tertentu dan memblokir pelaksanaan dari perintah lain selama pelaksanaannya. Redis OSS menggunakan notasi “Big O” untuk menggambarkan kompleksitas 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. KEYS dapat menyebabkan masalah dengan cara yang berbeda: Jika tidak menggunakan pola pencarian, perintah ini akan menghasilkan 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 ruang kunci untuk mencarinya, dan waktu untuk menyelesaikan perintah akan sama.

      Alternatif untuk KEYS adalah perintah SCAN. Perintah ini melakukan iterasi atas ruang kunci 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 default-nya 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 count sebesar 10 akan membutuhkan 100.000 pengulangan pada basis data dengan 1 juta kunci. Jika waktu pulang pergi 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. Namun, mesin akan sepenuhnya terblokir untuk operasi lain sampai perintah itu selesai menyapu semua ruang kunci.

      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 OSS menyediakan penerjemah Lua tertanam, memungkinkan eksekusi skrip di sisi server. Skrip Lua pada Redis OSS dieksekusi pada tingkat mesin dan bersifat atomik menurut definisi, yang berarti bahwa tidak ada perintah atau skrip lain yang diizinkan untuk dijalankan saat skrip sedang dieksekusi. Skrip Lua memberikan kemungkinan menjalankan beberapa perintah, algoritme pengambilan keputusan, penguraian data, dan lainnya langsung di mesin Redis OSS. Meskipun sifat atom dari skrip dan kemungkinan melepaskan aplikasi cukup menarik, skrip harus digunakan dengan hati-hati dan untuk operasi yang kecil. ElastiCacheAktif, waktu eksekusi skrip Lua dibatasi hingga 5 detik. Skrip yang belum ditulis ke ruang kunci 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 operasi tulis apa pun selama pelaksanaan skrip. Transaksi adalah alternatif untuk menjamin konsistensi beberapa modifikasi kunci terkait di Redis OSS. Perintah transaction memungkinkan eksekusi dari suatu blok perintah, memperhatikan perubahan pada kunci yang sudah ada. Jika salah satu kunci yang diperhatikan berubah sebelum selesainya transaksi, maka semua perubahan akan dibuang.

      • Penghapusan item secara massal: perintah DEL 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, sorted set, 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. Alternatifnya DEL adalahUNLINK, yang merupakan perintah asinkron yang tersedia sejak Redis OSS 4. UNLINKharus lebih disukai daripada DEL bila memungkinkan. Mulai ElastiCache (Redis OSS) 6x, lazyfree-lazy-user-del parameter membuat DEL perintah berperilaku seperti UNLINK saat diaktifkan. Untuk informasi selengkapnya, lihat Redis OSS 6.0 Perubahan Parameter.

      • 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 OSS menyediakan lebih banyak perintah yang bekerja 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. Namun, daftar parameter yang panjang akan memengaruhi 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 memengaruhi kompleksitas perintah dan karena itu berpengaruh pada 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 bekerja pada beberapa tipe data: Redis OSS juga menyediakan perintah yang bertindak atas satu atau beberapa kunci, terlepas dari tipe datanya. ElastiCache (Redis OSS) menyediakan metrik KeyBasedCmds untuk 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 menghabiskan banyak daya komputasi. 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 big data lainnya: Selain hash, struktur data lainnya dapat memakan waktu CPU. Set, List, Sorted Set, dan Hyperloglog juga dapat memakan waktu yang lama untuk dimanipulasi tergantung pada ukuran dan perintah yang digunakan. Untuk informasi selengkapnya tentang perintah tersebut, lihat https://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 tes di bawah ini Anda akan memerlukan ID ENI (Elastic Network Interface Identification) dari salah satu ElastiCache node yang tersedia di VPC Anda. Anda dapat menemukannya dengan melakukan hal berikut:

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

  2. Filter daftar antarmuka dengan nama ElastiCache cluster 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 mereka termasuk dalam ElastiCache cluster yang tepat dan pilih salah satunya.

  4. Lanjutkan ke langkah berikutnya.

  5. Buat jalur analisis di https://console.aws.amazon.com/vpc/home? # ReachabilityAnalyzer dan pilih opsi berikut:

    • Jenis Sumber: Pilih instance jika ElastiCache klien Anda berjalan pada instans Amazon EC2 atau Antarmuka Jaringan jika menggunakan layanan lain, seperti AWS Fargate Amazon ECS dengan jaringan awsvpc, dll) AWS Lambda, dan ID sumber daya masing-masing (instans EC2 atau ID ENI);

    • Jenis Tujuan: Pilih Antarmuka Jaringan dan pilih ElastiCache ENI dari daftar.

    • Port tujuan: tentukan 6379 untuk ElastiCache (Redis OSS) atau 11211 untuk (Memcached). ElastiCache Itu adalah port yang ditetapkan 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 Penjelajah analisis untuk detail di mana permintaan diblokir.

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

Untuk memvalidasi konektivitas TCP pada port ElastiCache layanan: Di Amazon Linux, Nping tersedia dalam paket nmap dan dapat menguji konektivitas TCP pada ElastiCache port, serta menyediakan waktu pulang-pergi jaringan untuk membuat koneksi. Gunakan ini untuk memvalidasi konektivitas jaringan dan latensi saat ini ke ElastiCache cluster, 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 batasan lain yang dimungkinkan di tingkat sistem operasi.

Di ElastiCache konsol, periksa apakah Enkripsi dalam transit diaktifkan di detail ElastiCache klaster Anda. Jika enkripsi bergerak 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 lulus tetapi aplikasi Anda masih tidak dapat terhubung ElastiCache, periksa apakah konfigurasi aplikasi sesuai dengan pengaturan. ElastiCache Kesalahan yang umum adalah:

  • Aplikasi Anda tidak mendukung mode ElastiCache klaster, dan ElastiCache memiliki mode cluster yang diaktifkan;

  • Aplikasi Anda tidak mendukung TLS/SSL, dan ElastiCache memiliki enkripsi dalam transit yang diaktifkan;

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

Batas terkait jaringan

  • Jumlah maksimum koneksi: Ada batas keras untuk koneksi secara serentak. Setiap ElastiCache node memungkinkan hingga 65.000 koneksi simultan di semua klien. Batas ini dapat dipantau melalui CurrConnections metrik pada. 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 (ElastiCache node) dan port yang sama. Perintah berikut menunjukkan berapa banyak koneksi yang ada untuk ElastiCache node 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 jumlahnya terlalu tinggi, sistem Anda mungkin menjadi kelebihan beban mencoba memproses permintaan koneksi. Sebaiknya mempertimbangkan menerapkan teknik seperti pooling koneksi atau koneksi persisten untuk menangani koneksi itu dengan lebih baik. Jika memungkinkan, lakukan konfigurasi pool koneksi untuk membatasi jumlah maksimum koneksi hanya beberapa ratus. Selain itu, logika back-off untuk menangani masalah waktu habis atau pengecualian koneksi lain juga dianjurkan untuk menghindari masalah koneksi churn.

  • Batas lalu lintas jaringan: Periksa CloudWatch metrik berikut untuk Redis OSS untuk mengidentifikasi kemungkinan batas jaringan yang terkena pada node: ElastiCache

    • 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 sarat operasi tulis mungkin tidak mampu mengatasi backlog replikasi. Untuk kasus seperti itu, praktik terbaiknya adalah menaikkan skala (mengubah jenis simpul), menskalakan ke luar (menambahkan serpihan dalam klaster dengan mode klaster diaktifkan), mengurangi jumlah replika, atau meminimalkan jumlah operasi 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 dataran tinggi teramati untuk waktu yang lama, kemungkinan akan diikuti oleh lag replikasi, peningkatan byte yang Digunakan untuk cache, penurunan memori yang dapat dikosongkan, swap tinggi, dan penggunaan CPU. Instans Amazon EC2 juga memiliki batas jaringan yang dapat dilacak melalui metrik 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 mempersempit kemungkinan masalah di ElastiCache samping:

  • Redis OSS SlowLogs: Konfigurasi ElastiCache default mempertahankan 128 perintah terakhir yang membutuhkan waktu lebih dari 10 milidetik untuk diselesaikan. Riwayat perintah lambat disimpan selama runtime 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 dalam grup parameter kustom. 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 di 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 (Redis OSS) menyediakan CloudWatch metrik untuk memantau latensi rata-rata untuk berbagai kelas perintah. 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 memengaruhinya.

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

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

    • GetTypeCmdsLatency: Baca perintah, terlepas dari tipe 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 atas tipe data yang berbeda: dump existskeys,object,pttl,,randomkey,ttl,type,del,expire,expireat,move,persist,pexpire,pexpireat,rename,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;

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

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

    • SetTypeCmdsLatency: Menulis perintah, terlepas dari tipe 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 runtime Redis OSS:

    • info commandstats: Menyediakan daftar perintah yang dijalankan sejak mesin Redis OSS dimulai, jumlah eksekusi kumulatifnya, total waktu eksekusi, dan waktu eksekusi rata-rata per perintah;

    • client list: Menyediakan daftar klien yang saat ini terhubung dan informasi yang relevan seperti penggunaan buffer, perintah yang dilaksanakan terakhir, dll;

  • Backup dan replikasi: ElastiCache (Redis OSS) versi lebih awal dari 2.8.22 menggunakan proses bercabang untuk membuat cadangan dan memproses sinkronisasi penuh dengan replika. Metode ini mungkin menyebabkan overhead memori yang besar untuk kasus penggunaan sarat operasi tulis.

    Dimulai dengan ElastiCache Redis OSS 2.8.22, AWS memperkenalkan metode pencadangan dan replikasi tanpa garpu. Metode yang baru dapat menunda operasi 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 periode pencadangan atau metrik SaveInProgress bernilai 1 pada periode tersebut. Sebaiknya menjadwalkan periode pencadangan untuk periode pemanfaatan yang rendah untuk meminimalkan kemungkinan masalah dengan klien atau kegagalan proses pencadangan.

Koneksi yang dihentikan dari sisi server

Konfigurasi default ElastiCache (Redis OSS) membuat koneksi klien tetap terjalin tanpa batas waktu. Namun, dalam beberapa kasus penghentian koneksi mungkin diinginkan. Misalnya:

  • Bug dalam aplikasi klien dapat menyebabkan koneksi dilupakan dan tetap terhubung dengan keadaan idle. Ini disebut “kebocoran koneksi “ dan konsekuensinya adalah peningkatan yang tetap pada jumlah koneksi terhubung yang diamati pada metrik CurrConnections. Perilaku ini dapat mengakibatkan kejenuhan pada klien atau ElastiCache sisi. Ketika perbaikan langsung tidak dimungkinkan dari sisi klien, beberapa administrator menetapkan nilai” batas waktu “dalam grup ElastiCache parameter mereka. Waktu habis adalah waktu dalam detik yang diizinkan bagi koneksi idle untuk bertahan. Jika klien tidak mengirimkan permintaan apa pun dalam periode tersebut, mesin Redis OSS akan menghentikan koneksi segera setelah koneksi mencapai nilai batas waktu. Nilai waktu habis yang kecil dapat mengakibatkan pemutusan koneksi yang tidak perlu dan klien akan perlu menangani ini dengan tepat dan menghubungkan 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. Konfigurasi default ElastiCache (Redis OSS) tidak membatasi ukuran buffer keluaran klien biasa. Jika batas maxmemory tercapai, mesin akan mencoba mengosongkan item untuk memenuhi penggunaan buffer. Dalam kondisi memori yang sangat rendah, ElastiCache (Redis OSS) mungkin memilih untuk memutuskan klien yang mengkonsumsi buffer output klien besar untuk membebaskan memori dan mempertahankan kesehatan cluster.

    Dimungkinkan untuk membatasi ukuran buffer klien dengan konfigurasi kustom 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 permintaan input tunggal;

    • client-output-buffer-limit-normal-soft-limit: Batas lunak untuk koneksi klien. Koneksi akan dihentikan jika tetap di atas batas lunak selama lebih dari waktu dalam detik yang ditentukan pada client-output-buffer-limit - normal-soft-seconds atau jika mencapai batas keras;

    • 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 daya tanggap di sisi klien juga dapat memengaruhi permintaan. 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 perincian titik data adalah 1 menit (dengan pemantauan terperinci diaktifkan) atau 5 menit;

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

    • Periode singkat penggunaan CPU yang tinggi dapat menyebabkan batas waktu tanpa mencerminkan pemanfaatan 100 persen. 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 selengkapnya, lihat Jenis Instans Amazon EC2.

    • Pada instans dengan ena penggerak Jaringan yang Ditingkatkan, periksa statistik ena untuk waktu habis 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 dicapai ketika lalu lintas jaringan terdiri dari ribuan atau jutaan permintaan yang sangat kecil per detik. ElastiCache Lalu lintas dapat dioptimalkan untuk memanfaatkan paket jaringan dengan lebih baik melalui saluran pipa atau perintah yang melakukan beberapa operasi sekaligus seperti MGET alih-alih. GET

Membedah waktu yang dibutuhkan untuk menyelesaikan satu permintaan tunggal

  • Di jaringan: Tcpdump dan Wireshark (tshark pada baris perintah) adalah alat yang berguna untuk memahami berapa banyak waktu yang dibutuhkan permintaan untuk melakukan perjalanan jaringan, menekan ElastiCache mesin dan mendapatkan pengembalian. 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 output di atas kita dapat mengonfirmasi bahwa handshake tiga arah TCP diselesaikan dalam 222 mikrodetik (918091 - 917869) dan perintah ping dikirim 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 untuk aplikasi atau debugger. Contoh berikut hanya menunjukkan jika komponen sistem operasi dasar berfungsi seperti yang diharapkan, jika tidak, penyelidikan lebih lanjut mungkin diperlukan. Menggunakan PING perintah Redis OSS yang sama 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 ini 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 hingga 717890), setelah itu, waktu 2 ms diperlukan untuk membuat soket TCP (745659 hingga 747858), dan waktu 0,4 ms (747858 hingga 748330) dibutuhkan untuk mengirimkan dan menerima respons untuk permintaan.