Buku putih ini menjelaskan penyebab layar patah-patah, karakter teleport, atau disconnect dengan membaginya menjadi 13 lapisan, dari layar game Anda sampai database server. Setiap penyebab dilengkapi cara memastikan dan tim penanggung jawabnya. Anda bisa memeriksanya dengan mengubah kondisi di simulasi. Contoh-contohnya berpusat pada MMO, tetapi sebagian besar berlaku untuk game online secara umum, apa pun genrenya.
Penyebabnya lebih dari seratus, tetapi faktor yang membuat lag bisa dikelompokkan menjadi empat: paket datang terlambat, datang tidak beraturan, tidak datang sama sekali, atau ada yang berhenti memproses. Game memakai berbagai teknik untuk menutupi faktor-faktor ini, dan jejak upaya menutupi yang gagal itulah “bentuk” lag yang terlihat di layar.
Di MMO, dunia yang terlihat di layar Anda adalah gambar yang disusun ulang dari paket kiriman server. Angkanya berbeda di setiap game, tetapi server biasanya menghitung state game 10–30 kali per detik (satu kali perhitungan ini disebut tick), lalu dari hasilnya hanya memilih perubahan di sekitar setiap pemain untuk dikirim sebagai paket. PC Anda membaca paket yang tiba, lalu menggambar layar. Karena itu, sebagian besar lag adalah soal cara game menampilkan “paket yang tidak datang tepat waktu”.
Ada juga kasus di luar keempat faktor itu. Jika server dan PC Anda menghitung hal yang sama dengan hasil berbeda (aturan gerakan yang berbeda, bug), rubber banding atau objek yang tidak terlihat bisa muncul meskipun koneksinya baik-baik saja. Petunjuk untuk lag jenis ini: lag berulang di tempat yang sama dan pada aksi yang sama, berapa pun ping-nya.
Bayangkan jasa kurir. Jika kiriman selalu tiba dalam 3 hari, itu latensi; jika ada yang tiba dalam sehari dan ada yang lima hari, itu jitter; jika kardusnya hilang, itu packet loss; jika gudang sortirnya tutup, itu stall. Game bertahan dengan cara seperti “jika kardus terlambat atau tidak datang, tebak isinya dari kardus sebelum dan sesudahnya (interpolasi dan ekstrapolasi)” dan “jika tidak datang, minta dikirim ulang (retransmisi)”.
Pembicaraan soal lag hampir selalu memakai satuan milidetik (ms, 1/1000 detik). Dengan mengingat beberapa angka saja di tabel berikut, Anda akan jauh lebih mudah memahami penjelasan Tim Pengembang Game dan Tim Infrastruktur.
| Acuan | Waktu | Arti |
|---|
CPU, disk, database, router, jalur ISP. Lapisannya berbeda, tetapi strukturnya sama. Ada worker yang memproses permintaan (core CPU, thread, koneksi DB, dan sebagainya), dan di depannya terbentuk antrean. Saat worker longgar, antreannya kosong, tetapi begitu tingkat kesibukannya (utilisasi) melewati 80–90%, antrean memanjang dengan cepat. Jika permintaan datang secara acak ke satu worker, rata-rata waktu tunggu sama dengan waktu pemrosesan pada utilisasi 50%, menjadi 4 kali lipatnya pada 80%, dan 9 kali lipatnya pada 90%. Inilah jawaban untuk pertanyaan “CPU masih sisa 10%, kenapa bisa lag?”. Selain itu, angka CPU di layar monitoring biasanya rata-rata dari beberapa core selama 1–5 menit, sehingga situasi saat hanya satu core yang 100% atau saat beban menumpuk selama beberapa detik saja jadi tidak terlihat.
Buku putih ini membahas penyebab lag saat bermain game online, mulai dari PC atau ponsel Anda yang menggambar layar game, jaringan rumah, ISP, data center, sampai server dan database. Cloud gaming yang mengirim layar game sebagai video, voice chat yang berjalan sebagai layanan terpisah, serta kecepatan patch dan download tidak dibahas karena strukturnya berbeda. Meski begitu, penyebab jaringan di dalamnya (Wi-Fi, bufferbloat, kongesti jalur, dan sebagainya) sama dengan penyebab yang ada di sini.
Saat Anda menekan tombol skill, sinyalnya melewati PC Anda, jaringan rumah, ISP, dan data center sebelum sampai ke server. Hasil yang diproses di berbagai lapisan di dalam server kembali melewati lapisan-lapisan yang sama dengan urutan terbalik, lalu digambar di layar. Totalnya ada 13 lapisan, dan lapisan mana pun yang tersumbat akan menimbulkan lag. Klik sebuah lapisan di peta berikut untuk membuka babnya.
Ini simulasi kecil yang terdiri dari satu server, satu koneksi, dan PC Anda. Rusak kondisinya satu per satu, lalu lihat bagaimana patah-patah, teleport, rubber banding, fast forward, slow motion, input lag, freeze, dan disconnect masing-masing terbentuk. Timeline paket menunjukkan dengan garis kapan setiap paket dikirim dan kapan paket itu tiba. Makin miring garisnya, makin lama perjalanannya, dan tanda × adalah paket yang hilang.
Pemain biasanya hanya bilang “lag”, tetapi bentuk lag memberi cukup banyak petunjuk tentang penyebabnya. Gambar kecil di setiap gejala adalah jejak yang dilewati karakter di layar. Titik yang menumpuk berarti karakter berhenti; titik yang merenggang berarti karakter bergerak lebih cepat atau melompati sebagian jalan.
Gerakan tidak mulus: berhenti sebentar, bergerak lagi, dan begitu terus berulang. Jika angka ping normal, kemungkinan besar masalahnya ada di frame PC Anda (klien atau OS). Jika ping naik turun, kemungkinan besar penyebabnya jitter dari Wi-Fi atau koneksi internet. Namun, ping di dalam game biasanya diukur di dalam game loop yang berjalan setiap frame, sehingga saat frame melonjak, angka ping juga bisa ikut melonjak.
Karakter langsung berpindah ke posisi yang jauh tanpa terlihat bergerak ke sana. Biasanya ini berarti paket sempat tidak datang selama beberapa saat. Periksa packet loss, koneksi yang putus sesaat, server yang berhenti, dan ekstrapolasi yang meleset. Jika pemain lain normal dan hanya satu orang yang teleport, koneksi orang itulah yang pertama dicurigai.
Karakter Anda sedang maju, lalu tertarik kembali ke posisi yang baru saja dilewati. Layar Anda (prediksi) tidak cocok dengan keputusan server. Bisa jadi input Anda tidak sampai ke server (packet loss), validasi gerakan di server memotongnya, atau perhitungan gerakan di klien dan server berbeda.
Layar yang tadinya diam bergerak lagi, lalu gerakan, serangan, dan damage yang tertunda lewat dengan cepat sekaligus. Paket sempat tertahan di suatu tempat, lalu dilepas sekaligus. Penyebab yang umum: TCP menunggu retransmisi, server mengejar ketertinggalan, dan pemrosesan di klien yang tertunda.
Semuanya bergerak lambat. Cast skill dan gerakan monster terlihat molor. Tergantung desain servernya, gejala ini juga bisa muncul sebagai patah-patah atau teleport dengan kecepatan yang tetap normal. Server tidak sempat menyelesaikan tick tepat waktu. Koneksinya baik-baik saja, jadi ping yang diukur di luar game tidak berubah; ping di dalam game bisa sedikit naik jika waktu tunggu pemrosesan server ikut terhitung di dalamnya. Periksa lonjakan jumlah pemain, perhitungan jarak pandang, broadcast, dan kekurangan memori.
Ada jeda antara saat tombol ditekan dan saat hasilnya muncul. Gambarnya sendiri bisa tetap mulus. Round-trip time (ping) tinggi, atau ada antrean yang menumpuk di suatu tempat. Periksa jarak, antrean router, Nagle (fitur TCP yang mengumpulkan paket kecil sebelum dikirim), dan antrean server. Jika ping rendah tetapi kontrol selalu terasa lamban, periksa sisi PC Anda (misalnya V-Sync atau FPS rendah) atau desain yang menunggu konfirmasi server untuk setiap aksi (bab model sinkronisasi).
Semua yang ada di layar berhenti sejenak (0,5 detik hingga beberapa detik), lalu bergerak lagi. Seluruh server berhenti (GC, deadlock, pemanggilan sinkron), koneksi putus sesaat, atau PC Anda yang berhenti.
Aksi yang jelas sudah dilakukan dianggap tidak pernah terjadi, atau hasilnya berbalik lama setelahnya. Permintaan hilang (packet loss, antrean meluap), server memutuskan hasil yang berbeda dari layar Anda (perbedaan waktu penilaian, ditolak setelah feedback sisi klien), atau penyimpanan gagal di tengah jalan (lock atau gangguan DB, server crash).
Koneksi terputus di tengah permainan, lalu Anda kembali ke layar login atau jendela reconnect. Tidak ada satu paket pun yang datang selama batas timeout. Periksa koneksi yang putus lama, idle timeout, server crash atau restart, serta server atau PC Anda yang berhenti lebih lama dari timeout (loading yang lama). Jika game tertutup sendiri tanpa pesan apa pun, periksa dulu kemungkinan klien tertutup paksa (crash, kehabisan memori) sebelum memeriksa koneksi.
Tidak bisa masuk ke dalam game, atau tertahan di layar loading atau layar masuk. Titik yang menerima koneksi baru (antrean koneksi server, firewall, server login, DB) sudah penuh. Ini sangat sering terjadi tepat setelah maintenance.
NPC, monster, atau pemain yang seharusnya ada tidak muncul hanya di layar Anda, atau objek yang sudah hilang masih tertinggal hanya di layar Anda. Ada satu paket yang terlewat atau objek gagal digambar. Kecepatan tidak banyak berperan di sini. Periksa perbedaan channel atau phasing, pesan spawn/despawn yang hilang, data yang dibuang saat loading, dan aset yang gagal dimuat. Petunjuk yang menentukan: apakah objek itu muncul setelah Anda keluar dari jarak pandang lalu kembali.
Ada game yang tetap terasa normal pada ping 150 ms, dan ada game yang sudah terasa lamban pada 60 ms. Ini tidak hanya berlaku untuk game action. Jika koneksinya sama, perbedaan ini biasanya berasal dari cara klien dan server menetapkan “apa yang diputuskan, kapan, dan oleh siapa”, yaitu desain sinkronisasi. Sebagian di antaranya adalah pilihan yang disengaja, dan sebagian lagi memang salah desain.
Semua game jaringan memecahkan masalah yang sama. Antara server dan PC Anda selalu ada selisih waktu, dan salah satu dari keduanya harus menentukan cara menangani hal yang “belum pasti”. Pada dasarnya ada empat pilihan.
Karena itu, seberapa sensitif sebuah game terhadap ping lebih banyak ditentukan oleh dua pertanyaan berikut daripada oleh genrenya: berapa kali satu aksi utama menunggu pulang-pergi ke server, dan apakah waktu yang diizinkan aturan game cukup longgar dibandingkan “ping + waktu reaksi manusia”.
| Model | Cara kerja | Umum dipakai di | Yang terlihat pada ping 150 ms | Titik lemah |
|---|---|---|---|---|
| Request-response Tampil setelah server mengonfirmasi | Saat tombol ditekan, klien bertanya ke server, lalu animasinya baru diputar setelah jawaban datang. | Game turn-based, kartu, dan idle; UI toko, trade, dan crafting; pemakaian skill dan item di MMO lama | Semua aksi mulai sekitar 0,2 detik lebih lambat. Di game turn-based hampir tidak terasa | Aksi beruntun, UI dengan banyak pulang-pergi dalam satu layar |
| Sinkronisasi state + interpolasi Otoritas server | Server mengirim state game setiap tick, dan klien menggambar transisi di antara dua state. | Tampilan pemain lain dan monster di sebagian besar MMO | Pemain lain terlihat dalam kondisi sekitar 0,2 detik yang lalu. Biasanya hampir tidak terasa | Jitter (variasi selang waktu kedatangan paket) dan packet loss → teleport, tick rate rendah |
| Prediksi sisi klien + rekonsiliasi server | Input Anda langsung diterapkan, lalu dibandingkan dan dikoreksi begitu hasil dari server datang. | FPS, MMO action, gerakan di sebagian besar MMO | Kontrol Anda langsung merespons. Sesekali rubber banding singkat | Koreksi sering terjadi jika perhitungannya berbeda dari server |
| Lag compensation Hit registration dengan rewind di server | Server memutar mundur waktu ke saat yang dilihat penyerang, lalu menentukan apakah serangan kena. | FPS, game action non-target | Penembak merasa adil, tetapi yang tertembak merasa “sudah berlindung, tetap kena” | Rasa tidak adil di pihak yang terkena. Makin tinggi ping penyerang, makin jauh waktu diputar mundur, dan makin parah rasa itu |
| Sinkronisasi perintah/tujuan | Hanya niatnya yang dikirim, seperti “pergi ke sini” atau “serang target ini”, lalu kedua sisi menghitung sendiri. | MMO dengan gerakan klik, pertarungan tab-target, sebagian MOBA | Hanya awal gerakan yang sedikit terlambat; gerakan dan serangan tetap mulus | Perlu koreksi jika jalur atau hasilnya tidak sama |
| Event terjadwal Berbasis waktu server | Server mengabarkan event bersama waktu di masa depan, misalnya “mulai pada waktu server T”, lalu setiap klien memutarnya pada waktu itu. | Pola boss raid, cutscene, event yang dimulai tepat di awal jam | Jika telegraph lebih panjang dari ping, praktis tidak ada pengaruhnya | Jika tiba lebih lambat dari jadwal, bagian awalnya terlewati |
| Deterministic lockstep | Input semua pemain dikumpulkan, lalu dihitung dengan cara yang persis sama pada giliran yang sama. Setiap input diberi input delay tetap. | RTS (keluarga StarCraft), sebagian game co-op dan puzzle | Semua input terlambat secara konsisten (ditutupi dengan efek suara dan tanda yang muncul begitu tombol ditekan). Jika jitter besar, game berhenti bagi semua pemain | Jitter dan packet loss, satu pemain yang paling lambat |
| Rollback Prediksi lalu rewind | Input lawan diprediksi dan game berjalan lebih dulu; jika prediksinya salah, game diputar mundur lalu dihitung ulang. | Game fighting (keluarga GGPO), sebagian game action dan olahraga | Kontrol terasa hampir instan (biasanya input delay 1–3 frame). Gerakan lawan sesekali melompat beberapa frame | Jika ping tinggi, rentang rewind melebar sehingga lawan terlihat seperti teleport |
| Otoritas klien | Setiap klien memutuskan hasilnya sendiri, dan server hanya meneruskan dan mencatat. | Sebagian game mobile dan kasual, struktur P2P dan relay | Layar Anda terasa lancar. Hasilnya tidak sama dengan layar pemain lain | Cheat, “di layar saya kena, tetapi tidak dihitung” |
Game sungguhan memakai campuran model-model ini. Biasanya model dipilih per aksi: gerakan dengan prediksi, skill dengan feedback sisi klien lalu dikonfirmasi server, pola boss dengan event terjadwal, dan trade dengan request-response.
1. Tidak ada satu pun pulang-pergi yang menyela satu aksi. Begitu tombol ditekan, animasi, efek suara, dan efek visual langsung dimulai (feedback sisi klien), sedangkan hasil dari server hanya dipakai untuk bagian yang tidak kentara meskipun terlambat, seperti angka damage.
2. Waktu yang diizinkan aturan game jauh lebih panjang dari ping. Jika telegraph boss berdurasi 1–2 detik, serangan masih bisa dihindari dengan leluasa meskipun paket datang sekitar 0,2 detik terlambat dan reaksi manusia memakan 0,25 detik. Jika skill Anda punya waktu cast, konfirmasi server ikut selesai selama cast bar terisi, sehingga waktu tunggunya tersembunyi di dalam waktu cast. Inilah alasan terbesar MMO tab-target tidak sensitif terhadap ping. Sebaliknya, telegraph pendek sekitar 0,5 detik sudah sulit dilihat lalu dihindari pada ping 150 ms (lihat simulasi timing window di bawah).
3. Aksi beruntun diterima lebih dulu. Jika ada input buffering (antrean skill) yang menyimpan skill berikutnya walaupun tombolnya ditekan sebelum cooldown selesai, waktu pulang-pergi tidak menyela di antara combo.
4. Jitter diserap. Buffer interpolasi dan animasi berbasis waktu server mengubah paket yang datang “biasanya dalam 150 ms, sesekali 250 ms” menjadi aliran yang konsisten dengan keterlambatan sekitar 250 ms. Yang terlihat sedikit lebih lampau, tetapi gerakannya mulus. Manusia cepat terbiasa dengan keterlambatan yang konsisten, tetapi sulit terbiasa dengan yang tidak beraturan. Game yang dibuat dengan baik memanjangkan dan memendekkan buffer secara otomatis mengikuti jitter yang membesar dan mengecil.
5. Keputusan server sesuai dengan “apa yang Anda lihat”. Menghindar dan kena dinilai berdasarkan saat yang dilihat pemain (lag compensation), atau aturannya sejak awal tidak bergantung pada posisi (target dipilih langsung).
6. Latensi satu pemain tidak membuat pemain lain menunggu. Pada struktur otoritas server, pemain lain tetap normal meskipun ping Anda buruk. Pada lockstep atau struktur host, satu pemain yang paling lambat menentukan rasa bermain semua orang.
Game bisa sensitif terhadap ping karena desain yang disengaja, bisa juga karena kesalahan pembuatan.
Saat tombol ditekan, tidak ada animasi maupun suara sampai jawaban server datang. Ping langsung menjadi kecepatan respons.
Mengapa: Skill, gerakan, dan pengambilan item baru diputar setelah konfirmasi server datang → Akibatnya: Sejak tombol ditekan, tidak ada respons apa pun selama waktu pulang-pergi + waktu tunggu tick → Di layar: Dengan ping 150 ms, setiap aksi terasa lamban 0,2 detik
Gejala: Input lag · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika satu aksi butuh beberapa kali pulang-pergi ke server secara berurutan, ping dikalikan sebanyak jumlah itu.
Mengapa: Buka toko → minta daftar → cek harga → beli → perbarui inventory, masing-masing diminta terpisah → Akibatnya: Permintaan berikutnya baru dikirim setelah jawaban permintaan sebelumnya diterima → Di layar: Dengan ping 150 ms, satu kali beli butuh hampir 1 detik. Loading terasa sangat lama
Gejala: Input lag, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika skill berikutnya baru bisa ditekan setelah ada konfirmasi bahwa skill sebelumnya selesai di server, waktu pulang-pergi menyela setiap kombo.
Mengapa: Input skill berikutnya hanya diterima “setelah skill sebelumnya dikonfirmasi” → Akibatnya: Di antara setiap skill muncul waktu kosong sebesar ping → Di layar: Ada celah di antara setiap kombo, dan makin tinggi ping makin rendah DPS
Gejala: Input lag, Aksi hilang / rollback · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika waktu untuk bereaksi pendek, seperti pada dodge, parry, atau guard, ping memakan waktu itu sehingga muncul serangan yang mustahil dihindari.
Mengapa: Timing window pendek, seperti telegraph serangan boss 0,5 detik atau parry window 0,2 detik → Akibatnya: Telegraph terlihat terlambat (latensi dari server ke klien + interpolasi), dan input Anda juga tiba terlambat (latensi dari klien ke server + waktu tunggu tick) → Di layar: Jelas sudah menghindar tetapi tetap kena, parry tidak terhitung
Gejala: Aksi hilang / rollback, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Jika server menilai serangan kena hanya dengan “posisi sekarang di server”, hasilnya tidak cocok dengan layar yang Anda lihat.
Mengapa: Lawan di layar Anda ada di posisi sekitar 0,2 detik di masa lalu (dengan ping 150 ms dan interpolasi 100 ms) → Akibatnya: Server menilai dengan posisi sekarang, jadi lawan sudah tidak ada di tempat yang Anda bidik → Di layar: Jelas kena tetapi meleset. Harus menembak mendahului target yang bergerak
Gejala: Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika server memutar mundur waktu terlalu jauh demi penyerang, pihak yang diserang tetap kena walaupun sudah bersembunyi.
Mengapa: Server memutar mundur waktu jauh demi penyerang yang ping-nya tinggi → Akibatnya: Di layar pihak yang diserang, ia sudah berlindung → Di layar: “Kena dari balik tembok”, pemain dengan ping tinggi diuntungkan
Gejala: Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika setiap klien memutuskan hasilnya sendiri, layar Anda terasa responsif, tetapi hasilnya tidak cocok dengan layar pemain lain dan rentan terhadap cheat.
Mengapa: Klien menentukan posisi dan hit, server hanya meneruskan → Akibatnya: Dua pemain sama-sama mengklaim mengenai lebih dulu, server tidak bisa memverifikasi → Di layar: Lawan teleport atau menembus tembok, “saya sudah mengenai, tetapi tidak terhitung”
Gejala: Teleport, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Dalam arsitektur tempat semua pemain menghitung giliran yang sama bersama-sama, jika input satu orang terlambat, semua orang menunggu.
Mengapa: Setiap giliran baru bisa dihitung setelah input semua pemain terkumpul → Akibatnya: Input satu orang tiba terlambat karena jitter atau packet loss → Di layar: Semua orang tersendat sesaat bersamaan; jika parah, muncul jendela “Menunggu pemain”
Gejala: Freeze, Patah-patah, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Input lawan diprediksi dan ditampilkan lebih dulu; jika prediksinya salah, game diputar mundur lalu dihitung ulang. Makin tinggi ping, makin lebar rentang rewind.
Mengapa: Lawan mengubah input (berbeda dari prediksi) → Akibatnya: Input sebenarnya tiba terlambat sebesar setengah ping, jadi game diputar mundur sebesar itu lalu dihitung ulang → Di layar: Gerakan lawan melompati beberapa frame atau tiba-tiba berubah
Gejala: Teleport · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika event dari server diputar begitu diterima tanpa diberi waktu kejadian, jitter jaringan langsung membuat timing animasi tidak beraturan.
Mengapa: Event “mulai serang” atau “putar efek” dijalankan begitu tiba → Akibatnya: Waktu tiba setiap paket berbeda sehingga intervalnya tidak beraturan → Di layar: Gerakan serangan beruntun kadang cepat kadang lambat, timing pola boss berbeda setiap kali
Gejala: Patah-patah, Fast forward · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika permintaan dikumpulkan sampai tick berikutnya untuk diproses, lalu hasilnya juga dikirim pada tick sesudahnya, interval tick bertambah dua kali.
Mengapa: Permintaan yang diterima diproses pada tick berikutnya → Akibatnya: Hasil pemrosesan juga dikumpulkan dan dikirim pada tick pengiriman berikutnya → Di layar: Ping koneksi rendah, tetapi respons selalu terlambat sekitar 1,5 kali interval tick. Pada server 10 tick, rata-rata 0,15 detik, terburuk 0,2 detik
Gejala: Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika server memeriksa kecepatan gerak, cooldown, dan jangkauan terlalu ketat, input normal yang datang bertumpuk akibat jitter pun ikut ditolak.
Mengapa: Kriteria ketat seperti “jarak yang boleh ditempuh dalam satu tick” atau “toleransi cooldown 0 ms” → Akibatnya: Jika dua perintah tiba bertumpuk dalam satu tick akibat jitter, server menganggapnya melanggar aturan → Di layar: Rubber banding, skill ditolak padahal cooldown sudah selesai
Gejala: Rubber banding, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika PC salah satu pemain berperan sebagai server, koneksi dan performa PC orang itu menentukan rasa bermain semua pemain.
Mengapa: PC host berperan sebagai server (P2P, listen server) → Akibatnya: Jika koneksi atau PC host lambat, dampaknya menyebar ke semua pemain, sementara ping host sendiri 0 → Di layar: Hanya host yang diuntungkan; jika host keluar, semua pemain freeze atau disconnect
Gejala: Patah-patah, Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Jika server kemudian tidak mengakui hit atau skill yang sudah lebih dulu ditampilkan di layar Anda, hasil yang jelas-jelas Anda lihat menjadi tidak pernah terjadi.
Mengapa: Efek hit dan animasi skill diputar lebih dulu sebelum konfirmasi server (feedback sisi klien) → Akibatnya: Server menimbang ulang jangkauan, posisi target, cooldown, dan resource, lalu menolak → Di layar: Darah muncrat tetapi tidak ada damage, hanya animasi skill yang keluar tanpa efek, hanya cooldown yang berjalan
Gejala: Aksi hilang / rollback, Rubber banding · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika yang dipertukarkan hanya “pergi ke sini” dan jalurnya dihitung masing-masing oleh kedua pihak, perbedaan perhitungan sekecil apa pun membuat karakter atau monster berjalan lewat jalur lain lalu ditarik kembali ke posisinya.
Mengapa: Pada click-to-move dan monster yang mengejar, hanya tujuan yang dikirim dan jalurnya dihitung terpisah oleh klien → Akibatnya: Bergerak lewat jalur yang berbeda dari server karena perbedaan data terrain, tabrakan dengan karakter lain, atau perbedaan urutan perhitungan → Di layar: Monster berjalan menembus tembok lalu tiba-tiba berpindah tempat, karakter yang diklik berbelok seperti meluncur
Gejala: Teleport, Rubber banding · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika server mengirim update posisi (snapshot) hanya beberapa kali per detik, buffer interpolasi harus dibuat lebih panjang sebanding, sehingga karakter lain terlihat di masa lalu yang lebih jauh.
Mengapa: Untuk menghemat volume kirim, update posisi hanya dikirim 5–10 kali per detik → Akibatnya: Agar gerakan tergambar mulus, buffer harus 2 kali interval paket (200–400 ms); jika lebih pendek, kehilangan satu paket saja sudah membuat gerakan terhenti → Di layar: Perubahan arah lawan terlihat terlambat dan tidak cocok dengan keputusan server. Jika buffer pendek, gerakan patah-patah dan teleport saat terjadi packet loss
Gejala: Patah-patah, Teleport, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Kasus paling membingungkan dalam laporan lag adalah saat hanya beberapa orang, atau hanya satu sisi, yang mengalaminya. Bagaimana satu pemain yang lambat terlihat di mata pemain lain, dan apakah pemain lain ikut melambat karenanya, bisa berbeda sama sekali tergantung pada cara server memproses input dan model sinkronisasinya. Bab ini juga membahas fenomena NPC yang tidak terlihat hanya di salah satu dari dua klien yang dibuka di PC yang sama.
Sebagian besar MMO saat ini memakai struktur otoritas server. Server menentukan semua hasil, dan klien menggambar hasil yang diterimanya. Dalam struktur ini, lag umumnya hanya muncul pada pemain yang lambat.
Namun, ada juga struktur yang membuat satu pemain lambat memperlambat semua orang. Kesamaannya: “ada yang menunggu pemain itu”.
| Cara server memproses input | Yang dialami pemain lambat itu sendiri | Pemain lambat di mata pemain lain | Game pemain lain sendiri |
|---|---|---|---|
| Kumpulkan per tick Tick tetap, input yang diterima diproses sekaligus | Hasil skill terlambat sebesar ping ditambah waktu tunggu tick (input lag). Jika validasi gerakan ketat, terjadi rubber banding | Tersendat sesaat, lalu maju beberapa langkah sekaligus (fast forward, teleport). Jika hanya ping yang tinggi tanpa jitter, gerakannya mulus | Tidak terpengaruh |
| Langsung saat tiba Berbasis event, langsung diterapkan dan dikirim begitu diterima | Input lag sebesar ping. Lebih cepat hanya sebesar waktu menunggu tick yang terlewati | Gerakannya kadang cepat, kadang lambat (fast forward ringan). Beberapa skill yang datang menumpuk dijalankan dalam sekejap | Tidak terpengaruh |
| Buffer input per pemain Input setiap pemain ditampung, lalu diambil satu per tick | Konfirmasi terlambat sebesar panjang buffer | Relatif mulus. Jika buffer kosong, sejenak diam di tempat | Tidak terpengaruh |
| Hit registration dengan lag compensation Rewind ke saat yang dilihat penyerang | Serangan kena sesuai bidikan (selama masih dalam batas rewind) | Serangannya tetap kena meskipun lawan sudah bersembunyi | Terkena serangan secara tidak adil (menjalar) |
| Lockstep/menunggu giliran | Input lag. Jika input terlambat, terjadi freeze | Semua pemain freeze | Freeze. Meskipun hanya terlambat, tetap terjadi input lag (menjalar ke semua pemain) |
| Pengiriman blocking/pemrosesan sinkron Server menunggu pemain itu | Freeze lalu fast forward | Semua pemain yang ditangani thread server itu ikut melambat | Slow motion/freeze (menjalar ke pemain yang ditangani thread itu) |
| Pemain lambat menjadi host P2P, listen server | Ping-nya sendiri 0 | Layar semua pemain patah-patah | Semua pemain lag |
| Kontrol monster dipegang pemain yang lambat Perhitungan gerakan monster diserahkan ke klien | Monster di layarnya sendiri normal | Monster yang ia tangani tersendat lalu teleport | Semua yang melawan monster itu (menjalar) |
Jika orang yang sama membuka dua klien di PC yang sama dan NPC tidak terlihat hanya di salah satunya, penyebabnya hampir tidak pernah koneksi. Kedua klien memakai router dan koneksi yang sama. Perbedaannya muncul di tiga titik.
Ada tiga petunjuk paling kuat: apakah name tag ada, tetapi model karakternya saja yang tidak ada (server sudah mengirim, tetapi gagal digambar), apakah objek muncul setelah Anda keluar dari jarak pandang lalu kembali (satu pesan spawn terlewat), dan apakah keadaannya membaik jika jendela yang bermasalah dibawa ke depan (pemrosesan dibatasi di jendela latar belakang). Sebaliknya, “objek hantu”, yaitu monster yang sudah mati tetapi masih berdiri hanya di layar Anda, terjadi karena pesan despawn terlewat.
Input dari pemain yang koneksinya buruk tiba di server secara tidak beraturan dan bertumpuk. Jika server menerapkan input sebanyak yang diterima di setiap tick, pemain lain melihat karakter itu tersendat sesaat, lalu maju beberapa langkah sekaligus.
Mengapa: Perintah gerak dari pemain yang lambat tiba dalam jumlah berubah-ubah: 0 di satu tick, 2–3 di tick lain → Akibatnya: Server menerapkan semuanya sekaligus di tick saat perintah diterima, sehingga posisi karakter itu berubah seperti anak tangga → Di layar: Di layar pemain lain, hanya karakter itu yang tersendat lalu bergerak sekaligus. Yang lain normal
Gejala: Fast forward, Teleport · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Pada server yang langsung memproses paket begitu tiba dan segera mengabarkan hasilnya, aksi pemain lambat yang datang bertumpuk langsung dijalankan berturut-turut.
Mengapa: Permintaan skill dan gerak dari pemain yang lambat tiba bertumpuk → Akibatnya: Server langsung menjalankannya sesuai urutan begitu diterima, lalu segera memberi tahu semua pemain → Di layar: Di mata pemain lain, pemain itu memakai beberapa skill dalam sekejap atau bergerak seperti dipercepat
Gejala: Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika server menampung sedikit input untuk setiap pemain lalu mengambilnya satu per tick, gerakan terlihat mulus di mata pemain lain, tetapi aksi pemain itu sendiri dikonfirmasi server lebih lambat sebesar itu.
Mengapa: Server menampung input pemain yang lambat di buffer, lalu menerapkannya satu per tick → Akibatnya: Buffer kecil sering kosong, sehingga karakter itu berhenti di tempat atau server menggerakkannya dengan menebak dari input terakhir. Buffer besar membuat input pemain itu sendiri lambat dikonfirmasi → Di layar: Buffer kecil: tersendat sesaat di mata pemain lain. Buffer besar: hasil skill pemain itu sendiri keluar terlambat (input lag)
Gejala: Patah-patah, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Input dari pemain yang koneksinya punya jitter besar tiba bertumpuk, sehingga sering terjaring pemeriksaan kecepatan dan cooldown di server.
Mengapa: Jitter koneksi di ISP atau wilayah tertentu membesar pada malam hari → Akibatnya: Server menganggap input normal yang tiba bertumpuk sebagai pelanggaran kecepatan atau cooldown → Di layar: Hanya pemain dari ISP itu yang mengalami rubber banding dan skill ditolak. Dalam kasus parah, server mengeluarkan mereka sehingga terjadi disconnect
Gejala: Rubber banding, Aksi hilang / rollback, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Pada mekanik raid yang menuntut semua pemain bereaksi bersamaan di saat yang ditentukan, reaksi terlambat dari satu pemain yang lambat membuat seluruh party gagal.
Mengapa: Mekanik bersama seperti “semua menyebar bersamaan” atau “satu orang menekan tombol” → Akibatnya: Pemain yang lambat melihat telegraph terlambat, dan input-nya juga tiba terlambat → Di layar: Seluruh party tewas (wipe) gara-gara satu orang itu, dan anggota party lain merasa “ini gara-gara orang yang lag”
Gejala: Aksi hilang / rollback, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Ada game yang menyerahkan perhitungan gerakan monster ke klien salah satu pemain di dekatnya untuk mengurangi beban server. Jika koneksi pemain itu buruk, monster itu bergerak aneh di layar semua pemain.
Mengapa: Server menyerahkan perhitungan gerakan monster ke klien pemain yang paling dekat (atau yang datang lebih dulu) → Akibatnya: Laporan hasil dari pemain yang memegangnya tiba di server terlambat atau bertumpuk → Di layar: Hanya monster itu yang tersendat lalu teleport di layar semua pemain di sekitarnya. Di layar pemain yang memegangnya, monster itu normal
Gejala: Teleport, Patah-patah, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Karakter yang menumpuk ribuan item atau mail, atau punya daftar teman, daftar blokir, dan buff yang sangat banyak, harus memuat, menyimpan, dan mengabarkan ke sekitarnya data yang berkali-kali lipat lebih besar dari karakter lain. Lambatnya hanya terjadi pada karakter itu, tanpa peduli koneksinya.
Mengapa: Pada karakter yang sudah lama dimainkan, atau akibat hadiah event, ribuan item menumpuk di inventory dan mailbox → Akibatnya: Setiap kali login, pindah area, atau menyimpan, data sebanyak itu dibaca dari dan ditulis ke DB, dan data equipment serta buff yang dikirim ke pemain di sekitar juga besar → Di layar: Hanya karakter itu yang loading masuknya lama dan tersendat sesaat saat membuka inventory atau mail. Pada server yang menunggu penyimpanan di thread game, pemain di sekitarnya pun ikut terhenti sebentar
Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika dua karakter berada di channel atau instance yang berbeda, atau di “phasing” berbeda yang menentukan NPC yang terlihat sesuai progres quest, keduanya melihat dunia yang berbeda.
Mengapa: Karakter kedua ditempatkan di channel lain, atau tahap quest-nya berbeda → Akibatnya: Server tidak mengirim NPC tersebut ke karakter itu (normal) → Di layar: NPC tidak ada hanya di salah satu sisi. Terlihat seperti bug, tetapi memang sesuai desain
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Begitu karakter masuk zona, server mengirim pesan spawn NPC di sekitarnya, tetapi klien masih memuat map sehingga pesan itu dibuang.
Mengapa: Server mengirim pesan spawn objek di sekitar tepat setelah proses masuk selesai → Akibatnya: Klien masih loading dan belum punya message handler, sehingga pesan itu dibuang → Di layar: Server menganggap pesan sudah terkirim dan tidak mengirim ulang. NPC tidak terlihat sampai karakter keluar dari jarak pandang lalu kembali
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika saat karakter didaftarkan ke grid jarak pandang bertepatan dengan saat NPC berpindah sel grid, pesan spawn NPC itu bisa terlewat.
Mengapa: Proses masuk, pindah channel, atau teleportasi karakter bertepatan dengan gerakan NPC → Akibatnya: NPC itu terlewat dari perhitungan “objek yang baru terlihat” → Di layar: Hanya beberapa NPC tertentu yang tidak terlihat, atau NPC yang sudah pergi masih tertinggal
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Pada server yang hanya mengirim “yang berubah sejak terakhir kali”, jika data lengkap yang dikirim sekali di awal (baseline) hilang, perubahan setelahnya tidak bisa diterapkan.
Mengapa: Paket data lengkap objek (baseline) hilang atau dibuang sebelum diproses → Akibatnya: Klien tidak punya dasar untuk menerapkan perubahan berikutnya, sehingga mengabaikannya → Di layar: Objek itu tidak terlihat, atau tiba-tiba muncul jauh kemudian
Gejala: Tidak terlihat / objek hantu, Teleport · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Sebaliknya, jika pesan “sudah hilang” terlewat, NPC atau pemain yang sudah mati atau pergi tetap tertinggal hanya di layar Anda.
Mengapa: Pesan bahwa objek mati, pergi, atau keluar dari jarak pandang hilang atau urutannya kacau → Akibatnya: Klien menganggap objek itu masih ada → Di layar: Monster yang tidak bereaksi saat diserang atau pemain yang sudah keluar masih berdiri
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Begitu karakter masuk zona, server mengirim data spawn puluhan hingga ratusan objek di sekitarnya sekaligus. Jika data ini dikirim lewat channel unreliable, atau buffer terima meluap selama klien tidak bisa membaca socket karena sedang loading, sebagian data hilang dan tidak dikirim lagi.
Mengapa: Tepat setelah masuk, data spawn tiba bertumpuk dalam waktu singkat → Akibatnya: Klien yang sedang loading terlambat membaca socket sehingga buffer terima OS meluap, atau paket UDP besar terfragmentasi sehingga satu fragmen saja yang hilang membuat seluruh paket hilang. Jika lewat channel unreliable, data itu juga tidak dikirim ulang → Di layar: Beberapa NPC hilang hanya di klien yang loading-nya lambat. NPC terlihat setelah karakter keluar dari jarak pandang lalu kembali
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika server memakai ulang ID objek yang sama saat NPC yang mati muncul kembali, klien yang melewatkan pesan despawn di antaranya salah mengira NPC baru sebagai NPC lama.
Mengapa: NPC mati, lalu muncul lagi dengan ID objek yang sama → Akibatnya: Klien yang melewatkan pesan despawn mengabaikan pesan spawn karena menganggapnya “objek yang sudah dikenal”, atau membiarkan objek itu tetap dalam keadaan mati → Di layar: NPC tidak ada atau terlihat tergeletak hanya di salah satu layar, kadang juga terlihat dengan wujud NPC lain
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika klien dibuat untuk memakai port lokal yang tetap, klien kedua di PC yang sama tidak bisa memakai port itu atau harus berbagi paket dengan klien pertama.
Mengapa: Dua klien mencoba membuka port UDP lokal yang sama (dipaksa berbagi dengan opsi reuse) → Akibatnya: OS hanya meneruskan paket masuk ke salah satu socket, atau tidak menjamin socket mana yang menerimanya. Router dan server juga melihat kedua klien sebagai alamat yang sama → Di layar: Salah satu klien tidak menerima paket dunia game, sehingga NPC dan pemain lain tidak terlihat atau terjadi disconnect
Gejala: Tidak terlihat / objek hantu, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika server atau server perantara membedakan koneksi berdasarkan IP atau ID perangkat, dua klien di PC yang sama (IP publik yang sama) dikenali sebagai satu orang.
Mengapa: Tabel sesi dibuat dengan kunci IP atau IP + ID perangkat → Akibatnya: Data klien kedua menimpa sesi pertama atau tercampur dengannya → Di layar: Di satu klien NPC tidak terlihat, sementara klien lainnya disconnect atau menerima data orang lain
Gejala: Tidak terlihat / objek hantu, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika modul keamanan atau kebijakan server membatasi beberapa klien di satu PC, klien kedua tidak bisa dijalankan atau masuk, atau klien yang dinyalakan lebih dulu terputus. Sebagian game hanya memblokir fitur pada klien tambahan.
Mengapa: Modul keamanan mendeteksi klien yang dijalankan ganda, atau server membatasi koneksi tambahan dari perangkat yang sama → Akibatnya: Menolak eksekusi atau koneksi kedua, atau memutus salah satunya. Dalam kasus yang jarang, hanya sebagian fitur klien tambahan yang diblokir → Di layar: Tidak bisa masuk, atau salah satu klien disconnect. Pada game yang hanya memblokir fitur, NPC atau toko tidak terlihat di salah satu klien saja
Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu, Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Untuk klien di jendela latar belakang, game, engine, dan OS mengurangi frame dan pemrosesan. Paket yang diterima tidak sempat diproses tepat waktu, sehingga menumpuk atau meluap.
Mengapa: Batas frame latar belakang di opsi game atau driver grafis (misalnya, di driver NVIDIA bisa diatur 20–200 frame per detik), mode hemat daya, pengaturan engine yang menghentikan game di latar belakang. OS juga memprioritaskan CPU dan GPU untuk jendela di depan (foreground) → Akibatnya: Jumlah paket yang diproses per frame berkurang sehingga antrean menumpuk, dan paket dibuang jika buffer terima meluap → Di layar: Saat jendela dibawa ke depan, semuanya muncul sekaligus, atau sebagian NPC tetap tidak terlihat
Gejala: Tidak terlihat / objek hantu, Fast forward, Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Jika dua klien menulis ke folder cache yang sama secara bersamaan atau mengunci file, salah satu klien gagal memuat model dan tekstur NPC.
Mengapa: Dua klien menulis file cache atau patch di folder instalasi yang sama secara bersamaan → Akibatnya: Pemuatan gagal karena file tidak bisa dikunci atau file yang baru setengah tertulis ikut terbaca → Di layar: NPC yang punya name tag tetapi tanpa model karakter, atau NPC yang transparan
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika dua klien berbagi memori grafis, tidak ada ruang untuk memuat model dan tekstur yang baru dibutuhkan, sehingga sebagian tidak tergambar.
Mengapa: Dua klien berbagi VRAM dan RAM. OS juga bisa lebih dulu mengurangi jatah memori grafis untuk jendela di latar belakang → Akibatnya: Engine tidak bisa memuat model dan tekstur baru, atau terus melepas lalu memuatnya lagi → Di layar: NPC muncul terlambat, tampak buram, atau tidak terlihat, disertai patah-patah
Gejala: Tidak terlihat / objek hantu, Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Jika opsi seperti batas jumlah karakter yang ditampilkan, penyembunyian name tag atau model NPC, dan mode grafis rendah berbeda di kedua klien, yang terlihat pun berbeda.
Mengapa: Hanya satu klien yang memakai “batas jumlah karakter di sekitar yang ditampilkan” atau mode grafis rendah → Akibatnya: NPC yang jauh atau berprioritas rendah tidak digambar (normal) → Di layar: NPC tidak ada hanya di salah satu sisi
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika klien kedua berasal dari instalasi lain atau patch-nya belum selesai, klien itu tidak mengenal ID NPC baru yang dikirim server dan diam-diam mengabaikannya.
Mengapa: Instalasi di folder lain, atau klien yang dijalankan saat patch masih berlangsung → Akibatnya: ID NPC atau ID model yang tidak dikenal dilewati → Di layar: Hanya NPC yang baru ditambahkan yang tidak terlihat di salah satu sisi
Gejala: Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika server membatasi volume kirim per koneksi dan mengirim objek yang dekat lebih dulu, koneksi dengan batas rendah menerima NPC yang jauh dengan terlambat atau tidak menerimanya sama sekali.
Mengapa: Di tempat ramai, server mengirim data sesuai urutan kepentingan dalam batas volume kirim per koneksi → Akibatnya: Koneksi dengan estimasi bandwidth rendah (misalnya, klien di jendela latar belakang yang lambat mengirim ACK) terus menunda objek di urutan belakang → Di layar: NPC yang jauh terlihat terlambat atau tidak terlihat hanya di salah satu sisi
Gejala: Tidak terlihat / objek hantu, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika waktu server yang diperkirakan klien salah, data objek yang baru tiba ditahan karena dianggap “masih di masa depan”, atau dibuang karena dianggap “sudah terlalu lama”.
Mengapa: Perkiraan waktu server di salah satu klien meleset jauh (diukur saat loading, atau setelah bangun dari mode hemat daya) → Akibatnya: Waktu acuan interpolasi tidak cocok dengan waktu data objek → Di layar: Objek muncul terlambat atau terlihat diam di tempat
Gejala: Tidak terlihat / objek hantu, Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Saat “retransmisi TCP (Retransmission)” di metrik server naik, laporan lag sering ikut naik. Retransmisi adalah tanda bahwa “paket hilang” atau “paket salah dianggap hilang”. Penyebabnya bisa ada di mana saja di sepanjang rute, dari Wi-Fi sampai kartu jaringan server, dan pada koneksi yang mengirim paket kecil secara jarang seperti game, satu paket yang hilang saja bisa berujung jeda ratusan ms. Bab ini merangkum akar penyebab retransmisi, cara menemukan penyebabnya, dan arah penyelesaiannya.
| Jenis | Kapan terjadi | Waktu sampai pulih | Yang terlihat di game |
|---|---|---|---|
| Fast retransmit Retransmisi cepat | Saat paket berikutnya tiba lebih dulu dan penerima memberi tahu bahwa “ada yang hilang di tengah” (duplicate ACK, SACK) | Round-trip time + waktu sampai 3 paket berikutnya tiba | Tersendat sesaat. Makin rapat paketnya, makin cepat pulih |
| RACK/TLP Deteksi packet loss berbasis waktu, kirim ulang paket terakhir | Paket yang dikirim belakangan sudah tiba, tetapi paket sebelumnya tidak datang dalam waktu tertentu; atau ACK tidak datang selama beberapa saat sehingga paket terakhir dikirim sekali lagi | Segera setelah konfirmasi paket berikutnya datang (RACK; karena bisa jadi urutannya hanya tertukar, RACK menunggu tambahan sekitar 1/4 round-trip time). Jika tidak ada paket berikutnya, sekitar 2 kali round-trip time (TLP); jika paket yang belum dikonfirmasi hanya satu, TLP menunggu 200 ms lagi untuk memperhitungkan delayed ACK | Tersendat sesaat yang relatif singkat, bahkan pada thin stream. Default di Linux terbaru |
| Retransmisi RTO Retransmission timeout | Saat waktu tunggu habis tanpa sinyal apa pun | Round-trip time + minimal 200 ms, berlipat dua setiap kali gagal | Freeze ratusan ms hingga beberapa detik, disusul fast forward; jika berlangsung lama, disconnect |
| Retransmisi SYN | Saat permintaan koneksi itu sendiri hilang (antrean koneksi atau backlog meluap, diblokir firewall) | 1 detik, 2 detik, 4 detik, 8 detik … (Linux 6.5 ke atas mengirim ulang dengan selang 1 detik sampai lima kali, lalu berlipat dua; Windows versi lama mulai dari 3 detik) | Terlambat dalam hitungan detik yang bulat, seperti 1 detik atau 3 detik setelah tombol masuk ditekan; jika terus gagal, tidak bisa masuk / loading tanpa henti |
| Retransmisi yang tidak perlu Spurious retransmission | Paket tidak hilang, tetapi datang terlambat atau urutannya tertukar, sehingga dikira hilang dan dikirim ulang | Tidak ada yang perlu dipulihkan, tetapi laju kirim tetap turun (Linux kadang mengembalikannya jika mendeteksinya lewat DSACK, yaitu pemberitahuan “sudah diterima” dari penerima, atau lewat timestamp) | Bandwidth terbuang, kecepatan transfer besar menurun. Di metrik, hanya tingkat retransmisi yang tinggi |
| Zero window probe Sering dikira retransmisi | Paket pengecekan yang dikirim saat buffer penerima penuh dan berada dalam status “jangan kirim dulu” | Sampai penerima mulai membaca lagi | Freeze. Koneksinya baik-baik saja; program penerima tidak membaca data tepat waktu |
Tingkat retransmisi adalah “persentase paket yang dikirim ulang dari semua paket yang dikirim”. Pada nilai kumulatif sejak boot, perubahan tenggelam di antara nilai normal, jadi hitung dari kenaikan selama selang waktu tertentu, misalnya 1 menit. Tidak ada standar resmi, tetapi sebagai gambaran kasar untuk rata-rata seluruh server: di bawah 0,1% berarti sehat, 0,1–1% berarti sebagian pemain sesekali tersendat, di atas 1% berarti dirasakan banyak pemain, dan di atas 3% berarti serius. Game dengan banyak pemain mobile atau luar negeri memang punya nilai normal yang lebih tinggi. Karena itu, selain angkanya sendiri, lihat juga berapa kali lipat kenaikannya dibandingkan biasanya. Rata-rata mudah tertarik oleh sejumlah kecil koneksi yang buruk, jadi memecahnya per wilayah, ISP, server, dan jam adalah jalan pintas untuk menemukan penyebabnya. Jika ada perangkat yang menerima koneksi di tengah jalan lalu membuat koneksi baru ke server (proxy, sebagian load balancer dan gateway), metrik server game hanya menangkap jalur antara perangkat itu dan server. Retransmisi di sisi pemain dilihat di perangkat tersebut.
| Di mana dilihat | Apa yang dilihat | Apa yang bisa diketahui |
|---|---|---|
| Seluruh server (Linux) | Kenaikan dari dua kali menjalankan nstat dengan selang 1 menit: TcpRetransSegs ÷ TcpOutSegs, serta TCPTimeouts, TCPLossProbes/TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv, TCPSynRetrans dari kelompok TcpExt | Tingkat retransmisi, berapa kali sampai RTO, berapa kali TLP dikirim dan berapa di antaranya benar-benar menutup packet loss, berapa kali paket yang dikirim ulang hilang lagi, retransmisi permintaan koneksi. Jika DSACK atau Spurious tinggi, artinya “dikirim ulang padahal tidak hilang”. OutSegs di Linux tidak mencakup retransmisi, jadi rasio yang tepat adalah RetransSegs ÷ (OutSegs + RetransSegs), tetapi di sekitar 1% selisihnya kecil |
| Per koneksi (Linux) | retrans (sedang dipulihkan/kumulatif), rto, backoff, rtt, cwnd, lost, reordering, bytes_retrans dari ss -ti | Apakah retransmisi hanya tinggi pada pemain atau wilayah tertentu, seberapa besar RTO sudah naik (backoff adalah berapa kali RTO berlipat dua secara beruntun). bytes_retrans ÷ bytes_sent adalah tingkat retransmisi koneksi itu |
| Per kejadian retransmisi (Linux) | Tool eBPF tcpretrans (bcc). -c untuk agregasi per koneksi, -l untuk menyertakan TLP | Menampilkan IP dan port remote serta status koneksi, satu baris setiap kali retransmisi terjadi. Ringan tanpa capture paket; cocok untuk memeriksa di rentang IP pemain atau server mana retransmisi terpusat |
| Kartu jaringan server | dropped, missed, crc dari ip -s -s link; rx_missed_errors, rx_no_buffer_count, rx_crc_errors, dan lainnya dari ethtool -S (namanya berbeda di setiap driver; di mlx5: rx_out_of_buffer, rx_discards_phy); kolom ke-2 (dropped) dan kolom ke-3 (time_squeeze) dari /proc/net/softnet_stat | Apakah kartu jaringan server membuang paket begitu diterima (ring buffer, CPU), atau kabel atau modul optiknya rusak (CRC). softnet_stat berisi satu baris per CPU dan ditulis dalam heksadesimal. Jika time_squeeze terus naik, core yang memproses penerimaan tidak sempat menyelesaikan tugasnya tepat waktu |
| Jaringan cloud | Untuk AWS ENA: bw_in_allowance_exceeded, bw_out_allowance_exceeded, pps_allowance_exceeded, conntrack_allowance_exceeded, linklocal_allowance_exceeded dari ethtool -S. Metrik ini tidak ada di tampilan default CloudWatch, jadi kumpulkan terpisah dengan CloudWatch agent | Apakah paket dibuang diam-diam karena batas instance. Jika nilainya terus naik, batasnya terlampaui. Cloud lain juga punya batas bandwidth dan jumlah koneksi per ukuran VM |
| Switch/router/firewall | CRC dan input error per port, output drop, policer terlampaui, pemakaian tabel sesi, log drop | Apakah paket dibuang di jalur perangkat data center. Jika utilisasi rata-rata 5 menit rendah tetapi output drop naik, itu microburst (lonjakan trafik dalam waktu yang sangat singkat) |
| Rute | Packet loss yang berlanjut sampai ujung rute, diukur dengan mtr atau pathping. Loss sekitar 1% baru terlihat setelah mengirim ratusan kali atau lebih, dan hasilnya lebih akurat jika dikirim ke port TCP yang sama dengan game (mtr -T -P PORT) | Mulai hop ke berapa packet loss terjadi. Jika hanya satu hop di tengah yang terlihat loss dan hop sesudahnya normal, perangkat itu hanya membatasi respons pengukuran (ICMP). Rute pergi dan pulang bisa berbeda, jadi ukur juga dari sisi server ke arah pemain |
| Capture paket (kedua ujung) | Filter Wireshark tcp.analysis.retransmission, serta fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment, zero_window dari kelompok tcp.analysis. yang sama | Jika paket asli ada di capture pengirim tetapi tidak ada di capture penerima, paket hilang di antara keduanya. Jika ada juga di capture penerima, itu retransmisi yang tidak perlu, atau ACK terlambat atau hilang dalam perjalanan kembali. Paket yang dibuang di ring buffer server penerima juga terlihat sebagai “hilang di antara keduanya” di capture, jadi periksa bersama counter kartu jaringan |
| Server Windows | TCPv4\Segments Retransmitted/sec ÷ Segments Sent/sec dan Network Interface\Packets Received Discarded di Performance Monitor, netsh int tcp show global, pktmon (bawaan Windows 10 1809 dan Server 2019 ke atas) | Tren tingkat retransmisi, apakah kartu jaringan membuang paket begitu diterima, konfigurasi TCP, di bagian mana di dalam Windows paket dibuang |
Urutan pemeriksaan: saat memeriksa bersama Tim Infrastruktur, urutan berikut paling cepat.
Jika laporan mencantumkan waktu (sampai detik), ISP dan wilayah pemain, server yang dipakai, dan nama gejala, Tim Infrastruktur bisa langsung mengikuti urutan ini.
1. Mencegah paket hilang (penyelesaian mendasar)
2. Mempercepat pemulihan
tcp_thin_linear_timeouts untuk thin stream; di Linux 6.15 ke atas, turunkan batas atas RTO dengan TCP_RTO_MAX_MSTCP_NODELAY untuk koneksi game (jika Nagle menahan paket baru dan tidak mengirimnya, tidak ada paket berikutnya yang bisa dipakai RACK)ip route … rto_min)TCP_USER_TIMEOUT dan heartbeat game3. Mengurangi kepekaan terhadap retransmisi (struktur)
TCP_NOTSENT_LOWAT dan sebagainya). Fast forward setelah freeze panjang menjadi lebih singkatSebagian besar pengaturan yang berkaitan dengan pemulihan retransmisi adalah pengaturan sistem operasi (kernel), dan hanya sedikit opsi socket yang bisa diaktifkan khusus untuk koneksi game. TCP_NODELAY, yang sering disalahpahami karena namanya, tidak mempercepat pemulihan. Namun, jika tidak diaktifkan (Nagle dipakai), paket baru makin terlambat selama pemulihan. Tabel berikut berlaku untuk Linux; di Windows, nama dan cakupan dukungannya berbeda.
| Pengaturan | Di mana | Apa yang diubah | Waspada |
|---|---|---|---|
TCP_NODELAY | Opsi socket | Mematikan Nagle. Pesan kecil langsung dikirim tanpa dikumpulkan | Menghilangkan jeda 40–200 ms yang muncul meskipun tidak ada packet loss. Timer retransmisi (RTO) itu sendiri tidak berubah. Namun, jika Nagle aktif, paket baru ikut tertahan selama menunggu pemulihan sehingga setelah pulih harus menunggu satu pulang-pergi lagi, dan paket berikutnya yang diandalkan fast retransmit dan RACK juga tidak terkirim sehingga mudah berujung RTO. Game biasanya mengaktifkannya |
net.ipv4.tcp_recovery (RACK) | Pengaturan kernel | Deteksi packet loss berbasis waktu. Tahan terhadap urutan yang tertukar, dan thin stream pun cepat pulih | Nilai default 1 (aktif). Masuk di Linux 4.4 dan mencapai bentuknya yang sekarang sekitar 4.18. Sejak 6.17, RACK menjadi satu-satunya metode deteksi packet loss, jadi mengubahnya ke 0 tidak berpengaruh. Tidak berjalan pada koneksi tanpa SACK |
net.ipv4.tcp_early_retrans (TLP) | Pengaturan kernel | Jika ACK tidak datang selama beberapa saat (sekitar 2 kali round-trip time), paket terakhir dikirim sekali lagi untuk cepat menemukan hilangnya paket-paket terakhir (tail loss) | Nilai default 3 (aktif), 0 berarti nonaktif. Butuh SACK agar berjalan. Jika paket yang belum mendapat ACK (in-flight) hanya satu, TLP menunggu 200 ms lagi sehingga hampir sama dengan RTO |
net.ipv4.tcp_sack, tcp_dsack, tcp_timestamps | Pengaturan kernel | Selective ACK (SACK, pemberitahuan bagian yang hilang di tengah), pemberitahuan penerimaan ganda (DSACK), pengukuran round-trip time (timestamp) | Secara default semuanya aktif. Ada server yang masih mematikannya sejak masalah keamanan SACK tahun 2019. Jika SACK dimatikan, RACK dan TLP juga ikut tidak berjalan |
net.ipv4.tcp_thin_linear_timeouts / TCP_THIN_LINEAR_TIMEOUTS | Pengaturan kernel / opsi socket | Pada koneksi dengan paket yang belum mendapat ACK (in-flight) kurang dari 4, RTO tidak dilipatgandakan sampai 6 kali pertama | Secara default nonaktif. Bisa diaktifkan khusus untuk koneksi game lewat opsi socket. Tidak memperpendek RTO pertama |
TCP_RTO_MAX_MS / net.ipv4.tcp_rto_max_ms | Opsi socket / pengaturan kernel (Linux 6.15 ke atas) | Menurunkan batas atas RTO yang berlipat dua (default 120 detik). Minimal 1 detik | Mencegah RTO membesar sampai puluhan detik setelah packet loss beruntun. Koneksi yang mati juga lebih cepat terdeteksi |
net.ipv4.tcp_mtu_probing | Pengaturan kernel | Jika paket besar terus hilang, ukurannya diperkecil agar bisa melewati MTU black hole | Default 0 (nonaktif). 1 = ukuran baru diperkecil jika retransmisi berlangsung sekitar 3 detik dan black hole dicurigai (selama itu data terhenti). 2 = sejak awal mulai dari 1.024 byte, lalu dicoba diperbesar sedikit demi sedikit |
ip route … rto_min | Pengaturan rute | Menurunkan nilai minimum RTO rute tersebut (default 200 ms) | Hanya untuk jaringan internal antarserver. Jika diturunkan pada jalur internet, retransmisi yang tidak perlu bertambah. net.ipv4.tcp_rto_min_us di Linux 6.11 ke atas berlaku untuk seluruh server, sehingga koneksi internet juga ikut berubah. Di 6.15 ke atas, opsi socket TCP_RTO_MIN_US bisa menurunkannya khusus untuk koneksi internal |
TCP_USER_TIMEOUT | Opsi socket | Lama waktu sampai koneksi dilepas saat retransmisi terus berlanjut | Tidak mempercepat pemulihan. Koneksi yang mati diputus cepat lalu reconnect. Jika tidak diatur, Linux baru memutus koneksi setelah retransmisi berlangsung sekitar 15 kali, kira-kira 15 menit (tcp_retries2) |
SO_KEEPALIVE + TCP_KEEPIDLE, dan lainnya | Opsi socket | Memeriksa apakah koneksi idle masih hidup | Terpisah dari retransmisi. Untuk mempertahankan mapping NAT dan LB serta mendeteksi koneksi yang mati |
fq qdisc + SO_MAX_PACING_RATE, BBR | Pengaturan qdisc / opsi socket / pengaturan kernel | Mengirim paket secara merata untuk mengurangi packet loss akibat burst (pengiriman yang menumpuk sekaligus) | Termasuk upaya “mencegah” packet loss. Terpisah dari kecepatan pemulihan |
Wi-Fi dan jaringan seluler mengirim ulang paket beberapa kali di jalur nirkabel, dan jika tetap gagal, paket dibuang. Paket yang dibuang itu baru dikirim ulang oleh TCP jauh kemudian.
Mengapa: Sinyal lemah atau interferensi berat membuat pengiriman di jalur nirkabel gagal berturut-turut → Akibatnya: Paket dibuang setelah melewati batas percobaan ulang perangkat nirkabel (biasanya beberapa hingga belasan kali) → Di layar: Freeze selama menunggu retransmisi TCP, lalu fast forward karena paket berikutnya yang tertahan di buffer terima diteruskan sekaligus
Gejala: Freeze, Fast forward, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Saat antrean di titik tersempit penuh, misalnya router rumah, jalur penghubung antar-ISP, atau jalur data center, paket yang baru datang dibuang.
Mengapa: Bottleneck penuh oleh trafik video, unduhan, dan pengguna lain → Akibatnya: Selama antrean penuh, paket yang baru datang dibuang berturut-turut (tail drop). Paket yang lolos pun menunggu di ujung antrean yang penuh → Di layar: Banyak paket hilang sekaligus sehingga terjadi freeze panjang lalu fast forward, sering pada malam hari
Gejala: Freeze, Fast forward, Rubber banding · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal), Pengembangan klien (Tim Pengembang Game)
Jika setiap tick server mengirim update untuk ribuan pemain sekaligus dalam sekejap, buffer kecil di switch atau batas sesaat di cloud meluap dalam waktu kurang dari 1 ms dan sebagian paket dibuang.
Mengapa: Paket untuk semua pemain dikirim sekaligus tepat saat tick dimulai → Akibatnya: Buffer port switch tempat trafik banyak server berkumpul (ratusan KB hingga beberapa MB per port) atau batas instance cloud meluap sesaat (utilisasi rata-rata tetap rendah) → Di layar: Banyak pemain teleport atau tersendat sesaat secara bersamaan, penyebabnya tidak terlihat dari metrik rata-rata
Gejala: Teleport, Freeze, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)
Batas kecepatan langganan ISP, batas instance cloud, dan perangkat proteksi DDoS kadang langsung membuang paket yang melewati kecepatan yang ditetapkan tanpa memasukkannya ke antrean.
Mengapa: Volume kirim sesaat melewati kecepatan atau burst yang diizinkan → Akibatnya: Paket yang melewati batas langsung dibuang tanpa antrean (policing) → Di layar: Setiap ada burst besar, beberapa paket hilang sehingga terjadi freeze lalu fast forward, padahal kecepatan rata-rata terlihat di bawah batas
Gejala: Freeze, Fast forward, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Kabel yang rusak, konektor serat optik yang kotor, dan modul optik yang sudah habis umur pakainya menimbulkan bit error, dan paket yang rusak dibuang diam-diam oleh perangkat.
Mengapa: Bit terbalik akibat kabel, modul optik, atau konektor yang rusak → Akibatnya: Perangkat membuang paket yang checksum (CRC)-nya tidak cocok → Di layar: Hanya pemain yang melewati jalur itu yang terus-menerus tersendat sesaat lalu mengalami fast forward, di jam berapa pun
Gejala: Freeze, Fast forward, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)
Jika satu sisi memakai autonegotiation sedangkan sisi lain mengunci kecepatan dan duplex, salah satu sisi berjalan dalam mode half duplex, dan paket hilang akibat collision setiap kali beban naik.
Mengapa: Kecepatan dan duplex dikunci hanya di salah satu perangkat → Akibatnya: Satu sisi berjalan full duplex, sisi lain half duplex, sehingga terjadi collision dan late collision → Di layar: Biasanya normal, tetapi saat trafik naik, semua pemain yang melewati perangkat itu mengalami freeze lalu fast forward
Gejala: Freeze, Fast forward · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Paket sudah sampai di server, tetapi dibuang karena ring buffer NIC (buffer yang menampung sementara paket yang tiba) meluap atau core yang menangani pemrosesan terima di kernel jenuh.
Mengapa: Lonjakan jumlah pemain, interrupt yang terpusat di satu core, CPU steal di virtual machine, atau virtual switch yang kelebihan beban → Akibatnya: Paket dibuang di ring buffer (rx_missed_errors dan sejenisnya, namanya berbeda tiap driver) atau di antrean terima kernel (softnet dropped) → Di layar: Saat pemain berkumpul, input terlambat diproses dan game tersendat sesaat di seluruh server secara bersamaan
Gejala: Input lag, Freeze, Fast forward, Teleport · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Firewall dan connection tracking Linux (conntrack, fitur yang mencatat koneksi yang lewat ke dalam tabel) membuang paket jika tabelnya penuh atau jika paket dianggap tidak sesuai dengan status koneksi.
Mengapa: Tabel connection tracking penuh (table full), atau rute pergi dan pulang berbeda sehingga hanya satu arah yang melewati firewall (rute asimetris) → Akibatnya: Firewall menganggap paket itu milik “koneksi yang tidak dikenal” atau membawa “nomor urut di luar rentang window”, lalu membuangnya → Di layar: Jika tabel penuh, koneksi baru terblokir; jika rutenya asimetris, hanya pemain di rute itu yang disconnect setelah retransmisi berulang
Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Firewall, perangkat pencegah intrusi (IPS), dan perangkat proteksi DDoS memeriksa setiap paket yang lewat. Begitu trafik melampaui kapasitas pemeriksaannya, paket yang tidak sempat diproses dibuang.
Mengapa: Lebih dari ratusan ribu paket game kecil per detik datang bersamaan pada jam sibuk atau saat event, atau aturan pemeriksaannya berat → Akibatnya: Batas CPU atau paket per detik perangkat penuh sehingga paket dibuang di perangkat. Jika terjadi false positive, paket normal pun diblokir → Di layar: Seluruh server di belakang perangkat itu mengalami freeze dan teleport bersamaan, makin parah hanya saat pemain berkumpul
Gejala: Freeze, Fast forward, Teleport, Disconnect · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika ukuran maksimum yang bisa dilewati suatu jalur di tengah rute mengecil dan notifikasi “terlalu besar” (ICMP) diblokir, paket besar terus hilang berapa kali pun dikirim ulang.
Mengapa: Ukuran maksimum mengecil di segmen VPN atau tunnel, dan notifikasi ukuran terlampaui diblokir firewall → Akibatnya: Pengirim terus mengirim ulang paket besar yang sama tanpa tahu sebabnya, dan RTO berlipat dua setiap kali → Di layar: Biasanya normal, tetapi saat data besar lewat (inventory, tempat ramai, loading saat masuk), paket kecil di belakangnya pun ikut berhenti, lalu berakhir dengan disconnect atau loading tanpa henti
Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Jika perangkat di tengah rute menghapus mapping koneksi idle (entri yang mencatat ke mana koneksi itu diteruskan), paket berikutnya tidak bisa diteruskan. Retransmisi terus berulang sampai pemain disconnect, atau perangkat membalas dengan penolakan koneksi (RST) sehingga pemain langsung disconnect.
Mengapa: Koneksi yang tidak dilewati paket selama beberapa waktu (AFK, di lobi) → Akibatnya: NAT di router, CGNAT ISP, firewall, load balancer, atau security group cloud menghapus mapping yang idle → Di layar: Begitu pemain bergerak lagi, retransmisi berlanjut hingga disconnect, atau langsung disconnect
Gejala: Disconnect, Freeze · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)
Paket hilang selama beberapa detik saat rute internet berubah, atau terus-menerus pada koneksi yang ditempatkan di jalur bermasalah di antara beberapa jalur ECMP.
Mengapa: Perhitungan ulang rute BGP, atau perangkat atau jalur yang rusak di salah satu dari beberapa jalur (ECMP, LAG) → Akibatnya: Packet loss sementara selama rute beralih, atau packet loss terus-menerus hanya pada koneksi yang melewati jalur itu → Di layar: Tiba-tiba freeze beberapa detik lalu fast forward, atau “membaik setelah reconnect” (ditempatkan di jalur lain)
Gejala: Freeze, Fast forward, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Paket sebenarnya tidak hilang dan hanya sesaat datang sangat terlambat, tetapi jika keterlambatan itu lebih lama dari RTO, pengirim menganggap paket hilang lalu mengirimnya ulang.
Mengapa: Bufferbloat, mode hemat daya Wi-Fi, transisi state radio seluler, atau virtual machine yang dijeda sesaat menimbulkan keterlambatan sesaat ratusan ms → Akibatnya: RTO habis lebih dulu sehingga paket dikirim ulang, lalu paket aslinya pun segera tiba (penerima menerima duplikat) → Di layar: Freeze dan fast forward disebabkan oleh lonjakan latensi itu sendiri. Retransmisi yang tidak perlu hampir tidak menambah lama freeze, tetapi menaikkan metrik retransmisi sehingga disangka packet loss
Gejala: Freeze, Fast forward, Input lag · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Jika urutan paket berubah saat melewati beberapa jalur atau link yang digabung, penerima memberi tahu “ada paket yang hilang” lewat duplicate ACK, dan pengirim mengirim ulang paket yang sebenarnya sudah sampai dengan baik.
Mengapa: Perangkat yang membagi rute per paket, LAG (gabungan link) yang membagi muatan per paket, dan momen saat rute berubah membuat urutan paket teracak → Akibatnya: Paket belakang tiba lebih dulu sehingga 3 duplicate ACK menumpuk → fast retransmit → Di layar: Paket game yang dikirim jarang-jarang hampir tidak terpengaruh. Update besar di tempat ramai dan unduhan patch melambat, sesekali patah-patah
Gejala: Patah-patah, Input lag · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Data sudah tiba dengan baik, tetapi jika ACK “sudah diterima” tertunda atau hilang di antrean upload yang penuh, pengirim menganggap data hilang lalu mengirimnya ulang.
Mengapa: Upload di rumah penuh oleh upload video atau backup cloud → Akibatnya: ACK tertunda ratusan ms di antrean router, atau dibuang saat antrean meluap → Di layar: Paket game dari server umumnya datang tepat waktu. Input Anda yang menumpuk di antrean upload yang sama terlambat terkirim sehingga terjadi input lag dan rubber banding, sesekali disertai retransmisi yang tidak perlu
Gejala: Input lag, Rubber banding · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika nilai minimum RTO diturunkan terlalu rendah, keterlambatan kecil saja sudah memicu retransmisi yang tidak perlu. Sebaliknya, nilai default (200 ms) terlalu panjang untuk game sehingga setiap kali paket hilang, game berhenti lama.
Mengapa: Nilai minimum RTO diturunkan drastis untuk keperluan data center, atau nilai default dipakai apa adanya di jalur internet → Akibatnya: Terlalu rendah: retransmisi membanjir bahkan saat latensi naik sesaat. Terlalu tinggi: setiap packet loss harus ditunggu lama → Di layar: Dengan nilai default, satu kali packet loss membuat freeze ratusan ms lalu fast forward; jika diturunkan terlalu rendah, freeze memendek, tetapi retransmisi yang tidak perlu melonjak dan memboroskan bandwidth
Gejala: Freeze, Fast forward, Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika game mengirim paket kecil secara jarang-jarang, RTO datang lebih dulu sebelum “3 paket susulan” terkumpul. Untuk packet loss yang sama, game berhenti jauh lebih lama daripada transfer data besar.
Mengapa: Interval paket sekitar 100 ms sehingga hanya ada sedikit paket yang belum mendapat ACK (in-flight) → Akibatnya: Butuh lebih dari 300 ms untuk mengumpulkan 3 duplicate ACK sehingga RTO (ping + 200 ms) terpicu lebih dulu, dan berlipat dua jika packet loss terjadi berturut-turut → Di layar: Satu kali packet loss membuat freeze sekitar 0,3 detik; jika paket yang dikirim ulang juga hilang, freeze hampir 1 detik lalu fast forward
Gejala: Freeze, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Jika sebagian firewall atau perangkat akselerator menghapus atau mengubah opsi TCP, saat beberapa paket hilang, pemulihannya hanya satu paket per round trip, atau window (jumlah yang bisa dikirim sekaligus) mengecil sehingga koneksi melambat.
Mengapa: “TCP normalization” di firewall atau perangkat akselerator lama menghapus opsi SACK, timestamp, dan window scaling → Akibatnya: Jika beberapa paket hilang, pemulihannya satu paket per round trip, dan window dibatasi 64 KB → Di layar: Freeze di setiap packet loss jauh lebih lama (tanpa SACK, RACK-TLP juga tidak bisa dipakai), lalu fast forward setelah pulih. Transfer data besar seperti patch juga lambat
Gejala: Freeze, Fast forward · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika program penerima tidak membaca socket tepat waktu sehingga buffer penuh, pengirim menghentikan pengiriman dan hanya mengirim zero window probe. Koneksinya sendiri baik-baik saja.
Mengapa: Frame di klien berhenti atau thread server tertahan sehingga socket tidak terbaca → Akibatnya: Receive window menjadi 0 sehingga pengirim berhenti mengirim dan hanya mengirim probe (intervalnya makin panjang) → Di layar: Freeze lalu fast forward. Packet capture menunjukkan “ZeroWindow” dan tidak ada packet loss
Gejala: Freeze, Fast forward · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Jika permintaan koneksi hilang karena antrean koneksi (backlog) meluap atau diblokir firewall, OS klien mengirimnya ulang mulai 1 detik kemudian dengan interval yang makin panjang.
Mengapa: Lonjakan koneksi tepat setelah maintenance membuat antrean koneksi server meluap, atau firewall dan proteksi DDoS membuang SYN → Akibatnya: OS klien mengirim ulang SYN mulai 1 detik kemudian dengan interval yang sudah ditentukan (Linux versi lama: 1 detik → 2 detik → 4 detik) → Di layar: Setelah tombol masuk ditekan, keterlambatannya pas dalam hitungan detik seperti 1 atau 3 detik, dan jika terus gagal, pemain tidak bisa masuk atau mengalami loading tanpa henti
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Lag yang sama bisa diperbaiki oleh pihak yang berbeda. Kode klien dan server serta desain sinkronisasi ditangani Tim Pengembang Game, sedangkan jalur, perangkat jaringan, server, dan server DB ditangani Tim Infrastruktur. Masalah di PC dan jaringan rumah pemain, jalur ISP, dan sisi penyedia cloud tidak bisa diperbaiki langsung oleh kedua tim, jadi ditangani lewat panduan, permintaan, atau solusi sementara. Setiap kartu penyebab mencantumkan penanggung jawab utama dan pihak yang turut terlibat, dan jika bagian “Kisaran angka·Cara memastikan·Penanganan per tim” di kartu dibuka, tugas setiap tim tercantum terpisah.
| Penanggung jawab | Cakupan tanggung jawab | Solusi yang umum dipakai |
|---|---|---|
| Tim Pengembang GameKlien | Kode klien game: frame, GC, dan loading; interpolasi, ekstrapolasi, dan prediksi; pemrosesan jaringan di klien (termasuk pengiriman heartbeat dan reconnect otomatis) | Perbaikan kode, penyesuaian buffer interpolasi dan prediksi, perubahan cara loading, interval heartbeat dan alur reconnect, patch klien |
| Tim Pengembang GameServer | Kode server game: tick, thread, dan lock; desain sinkronisasi; penanganan koneksi (loop accept, argumen listen); respons heartbeat dan pembersihan koneksi yang terputus; opsi socket; desain query dan transaksi | Optimasi logika, pemanggilan asinkron, distribusi tick dan area, antrean login, melanjutkan sesi dengan token sesi, opsi socket (TCP_NODELAY dan lainnya), desain query dan indeks, patch server |
| Tim InfrastrukturJaringan | Jalur dan perangkat jaringan data center (switch, router, firewall, load balancer, proteksi DDoS); network ACL, routing VPC, dan load balancer di cloud; ISP dan peering | Konfigurasi dan penggantian perangkat, penambahan kapasitas jalur dan peering, perubahan rute, eskalasi ke ISP, penyesuaian idle timeout dan batas sesi di load balancer dan firewall |
| Tim InfrastrukturServer/OS | Server fisik dan instance cloud (termasuk security group dan connection tracking), konfigurasi OS dan kernel, NIC, lingkungan deploy dan monitoring | Penambahan server dan perubahan tipe instance, konfigurasi kernel (sysctl: somaxconn, conntrack, dan lainnya), konfigurasi security group dan waktu connection tracking, ring buffer NIC dan distribusi interrupt, penyesuaian jadwal cron dan backup |
| Tim InfrastrukturServer DB | Server DB dan storage; konfigurasi, replikasi, dan backup DB; server cache | Penambahan kapasitas DB, penyediaan IOPS storage, konfigurasi parameter dan replikasi DB, penyesuaian backup dan checkpoint |
| Pihak EksternalPemain/ISP/cloud | PC dan jaringan rumah pemain, jalur ISP (di luar kontrak kami), penyedia cloud | Panduan untuk pemain (misalnya memakai koneksi kabel), permintaan ke ISP dan penyedia cloud, solusi sementara dan mitigasi di sisi game |
Angka tebal adalah jumlah penyebab dengan penanggung jawab utama tersebut, dan angka bertanda + adalah jumlah penyebab yang ikut ditanganinya. Klik sebuah sel untuk menampilkan penyebab dan tugas tim di bawahnya.
Penanggung jawab utama adalah tempat akar penyebab berada, atau pihak yang bisa menghilangkannya. Meskipun penyebabnya ada di jalur atau perangkat, Tim Pengembang Game tetap bertahan sementara itu dengan desain yang mengurangi dampaknya (buffer interpolasi, pengiriman input ganda, reconnect). Sebaliknya, jika penyebabnya ada di kode server, penambahan perangkat oleh Tim Infrastruktur hanya menunda masalah sesaat. Batas yang sering membingungkan ditetapkan sebagai berikut.
Label “Hubungi dulu” di tabel menunjukkan pihak yang dihubungi pertama, ditentukan dengan menghitung penanggung jawab utama dari kartu-kartu penyebab yang sesuai dengan fenomena itu. Jika ada dua pihak, yang di depan adalah pihak yang paling banyak menjadi penanggung jawab utama, dan yang di belakang adalah pihak yang sejak awal ikut dihubungi.
| Fenomena | Tugas Tim Pengembang Game | Tugas Tim Infrastruktur | Metrik yang diperiksa pertama |
|---|---|---|---|
| Packet loss dan jitter tinggi di ISP atau wilayah tertentu Hubungi duluTim InfrastrukturJaringan | Buffer interpolasi adaptif, pengiriman input bertumpuk, pengiriman UDP yang tahan packet loss, mengambil IP, port, dan waktu pemain yang terdampak dari statistik packet loss dan retransmisi per koneksi, melonggarkan kriteria validasi gerakan sesuai kondisi koneksi | Pengukuran rute dua arah (mtr) dengan protokol dan port yang sama dengan game, mengeluarkan rute yang buruk, eskalasi ke ISP, menambah peering dan jalur | Distribusi tingkat packet loss dan jitter per ISP, tingkat retransmisi |
| Retransmisi TCP meningkat Hubungi duluTim InfrastrukturJaringanTim Pengembang GameServer | TCP_NODELAY, menyebar pengiriman satu tick di dalam tick, membaca socket tepat waktu (mencegah zero window), mempertahankan mapping dengan heartbeat, memindahkan paket real-time ke UDP atau koneksi lain, tidak menumpuk posisi lama di buffer kirim (TCP_NOTSENT_LOWAT) | Menghilangkan titik packet loss (kabel, modul optik, duplex, policer, connection tracking di firewall, MTU), penyesuaian MSS, ring buffer dan distribusi interrupt di server, pengaturan pemulihan di kernel (RACK, tcp_mtu_probing) | Kenaikan retransmisi (nstat), jumlah zero window, counter drop dan CRC di NIC dan port switch |
| Tick melewati budget karena CPU server jenuh Hubungi duluTim Pengembang GameServer | Optimasi perhitungan jarak pandang dan broadcast, membagi tick ke beberapa thread, membagi area dan channel yang padat, menyesuaikan jumlah worker thread dengan batas CPU, mencatat waktu pemrosesan tick sebagai metrik | CPU atau instance dengan performa single-core (clock) tinggi, alert utilisasi CPU per core, memeriksa CPU steal dan CPU throttling container, memisahkan core pemroses interrupt dari core thread tick | Waktu pemrosesan tick, utilisasi CPU per core, steal, jumlah throttling (nr_throttled) |
| Respons DB lambat Hubungi duluTim Pengembang GameServerTim InfrastrukturServer DB | Desain query, indeks, dan transaksi (singkat, urutan lock seragam), pemanggilan asinkron di luar thread game, query gabungan dan cache, penyesuaian ukuran connection pool dan timeout tunggu | Menemukan slow query, query plan, dan waktu tunggu lock lalu membagikannya ke Tim Pengembang Game, pengaturan checkpoint, replikasi, dan pembaruan statistik, IOPS storage, memastikan jumlah server × ukuran pool masih di bawah jumlah koneksi maksimum, menambah kapasitas server DB | Log slow query, waktu tunggu lock, waktu tunggu koneksi, replication lag, IOPS |
| Tidak bisa masuk tepat setelah maintenance Hubungi duluTim Pengembang GameServer | Menjaga thread yang menerima koneksi (loop accept) agar tidak tertahan oleh pekerjaan lain, memperbesar argumen backlog pada listen, sistem antrean login, menggabungkan query login (menghilangkan N+1), memperpanjang interval retry klien sambil menyebarnya secara acak | somaxconn dan SYN cookie di kernel, batas sesi di firewall dan load balancer, batas conntrack dan file descriptor di server, warm-up cache DB, scaling server lebih awal sebelum event | ListenOverflows, utilisasi tabel sesi dan conntrack, jumlah query login dan waktu tunggu koneksi |
| Disconnect setelah lama diam Hubungi duluTim Pengembang GameKlien | Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (agar heartbeat berikutnya tetap sampai sebelum timeout meskipun satu heartbeat terlambat atau hilang), reconnect otomatis jika koneksi terputus. Server: jawab heartbeat, bersihkan koneksi lebih dulu jika heartbeat tidak diterima selama waktu tertentu, lanjutkan sesi dengan token sesi. | Kumpulkan idle timeout load balancer dan firewall di sepanjang rute (Jaringan) serta waktu connection tracking security group cloud (Server/OS), lalu bagikan ke Tim Pengembang Game; perpanjang untuk perangkat kami jika perlu. Timeout router pemain dan CGNAT ISP tidak bisa diubah | Distribusi waktu idle koneksi yang terputus (jika terpusat di sekitar satu nilai, itulah perangkat dengan timeout tersebut), jenis jaringan (seluler, kabel) |
| Server berhenti pada waktu-waktu yang tetap Hubungi duluTim Pengembang GameServerTim InfrastrukturServer/OS | Sebar secara acak waktu event tepat di awal jam, penyimpanan, timer, dan kedaluwarsa cache; pecah query batch menjadi bagian kecil dan jalankan sedikit demi sedikit; pilih secara eksplisit GC dengan jeda singkat | Sebar jadwal cron, backup, dan kompresi log serta turunkan prioritas I/O-nya, jalankan backup DB di replika dan ratakan checkpoint, periksa burst credit disk, batasi kecepatan transfer backup | Waktu server berhenti dan jadwal pekerjaan (cron, backup, batch, checkpoint), log GC |
| DDoS/lonjakan trafik Hubungi duluTim InfrastrukturJaringan | Membagikan pola trafik game (port, ukuran paket, jumlah paket per detik) ke Tim Infrastruktur, membatasi frekuensi permintaan per akun dan karakter, memblokir paket abnormal sejak awal | Proteksi DDoS (scrubbing) dan aturan proteksi yang disesuaikan dengan trafik game, menyembunyikan alamat server, batas paket per detik di perangkat; pembatasan berbasis IP harus memperhitungkan IP bersama ISP dan warnet | Jumlah paket per detik, CPU dan drop di perangkat, tingkat kegagalan koneksi per wilayah dan ISP (cek false positive) |
| Masalah Wi-Fi atau PC pemain Hubungi duluPihak EksternalPemain/ISP/cloudTim Pengembang GameKlien | Tampilan status jaringan di dalam game (ping, packet loss), panjang buffer interpolasi yang menyesuaikan otomatis mengikuti jitter, mencatat jenis jaringan dan utilisasi CPU PC di log saat terjadi lag, teks panduan seperti anjuran memakai koneksi kabel | Tidak bisa diperbaiki langsung. Jika laporan terpusat di ISP atau wilayah yang sama, klasifikasikan ulang sebagai masalah jalur ISP | Info koneksi dan perangkat dalam laporan, rasio laporan dari ISP dan wilayah yang sama |
Tim Pengembang Game → Tim Infrastruktur
Tim Infrastruktur → Tim Pengembang Game
Untuk kedua tim: tunjuk satu pemimpin penanganan insiden, catat kronologi di satu channel, dan umumkan lebih dulu waktu pembaruan berikutnya. Jika penanggung jawab utama berpindah ke tim lain, serahkan catatan ini juga agar pemeriksaan yang sama tidak diulang. Setelah selesai, gunakan catatan yang sama untuk memperbarui penanggung jawab dan tugas di kartu penyebab terkait.
Inilah program game itu sendiri yang berjalan di PC atau ponsel pemain. Meskipun jaringannya sempurna, layar akan patah-patah jika frame terlambat di sini. Lapisan ini juga menentukan seberapa baik kondisi jaringan yang buruk bisa ditutupi.
Game mengulang pekerjaan yang sama sekitar 60 kali per detik: membaca input, memproses paket yang diterima, memajukan state game satu langkah, lalu menggambar layar. Satu putaran loop ini adalah satu frame. Pada 60 FPS, setiap frame mendapat jatah 16,7 ms (33,3 ms untuk game ponsel yang berjalan di 30 FPS). Jika satu frame terlambat, layar diam selama keterlambatan itu, lalu pada frame berikutnya semua yang tertunda bergerak sekaligus.
Di sisi jaringan, tugas klien adalah “mengisi informasi yang kurang”. Posisi pemain lain datang dari server secara berselang, jadi celah di antaranya harus disambung (interpolasi). Jika paket terputus, gerakan harus ditebak (ekstrapolasi). Karakter Anda sendiri langsung ditampilkan bergerak tanpa menunggu konfirmasi server (prediksi). Saat teknik-teknik ini gagal, hasilnya adalah teleport, rubber banding, dan patah-patah.
Klien game adalah ruang kontrol stasiun TV yang menyusun siaran langsung. Foto dari lokasi (server) datang berselang, lalu celah di antaranya disambung dengan mulus sehingga tampak seperti video. Jika foto datang terlambat, tidak ada foto untuk disambung sehingga layar berhenti. Jika ruang kontrolnya sendiri sedang sibuk, siaran juga terputus.
Perhitungan satu frame memakan waktu beberapa kali lebih lama dari biasanya sehingga layar berhenti sejenak.
Mengapa: Jumlah efek skill melonjak, spawn massal, dan pembaruan seluruh UI menumpuk dalam satu frame → Akibatnya: Tidak selesai dalam 16,7 ms dan memakan 50–300 ms → Di layar: Layar tersendat sesaat, lalu di frame berikutnya semua karakter berpindah sekaligus
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Selama memori bekas pakai (garbage) dikumpulkan kembali, seluruh game berhenti. Cirinya adalah patah-patah dengan interval yang teratur.
Mengapa: Setiap frame membuat lalu membuang string, array, dan list sementara → Akibatnya: Saat garbage menumpuk, GC menghentikan main thread untuk mengumpulkannya → Di layar: Patah-patah secara teratur setiap beberapa detik hingga puluhan detik
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Game berhenti karena harus membaca file dan membuat shader tepat sebelum menggambar area, monster, atau efek yang baru pertama kali muncul.
Mengapa: Masuk area baru, skill, equipment, atau monster yang baru pertama kali muncul → Akibatnya: Main thread menunggu pembacaan file dan kompilasi shader → Di layar: Berhenti 0,1–1 detik hanya pada kali pertama, setelah itu normal
Gejala: Freeze, Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Pada storage lambat seperti HDD, kecepatan membaca tekstur dan model di open world tidak bisa mengimbangi gerakan pemain, sehingga objek terlambat muncul atau game patah-patah karena menunggu pembacaan selesai.
Mengapa: Bergerak cepat dengan tunggangan atau teleportasi, atau masuk ke tempat ramai, sehingga banyak tekstur dan model baru dibutuhkan sekaligus → Akibatnya: Storage lambat seperti HDD tidak bisa membaca secepat yang dibutuhkan sehingga permintaan baca menumpuk, dan sebagian loading membuat main thread menunggu sampai selesai → Di layar: Tekstur buram untuk sementara, bangunan dan karakter terlambat muncul, dan saat menunggu pembacaan terjadi patah-patah atau freeze
Gejala: Tidak terlihat / objek hantu, Patah-patah, Freeze · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Saat ratusan karakter masuk ke satu layar seperti di siege atau world boss, biaya menggambarnya saja sudah tidak sanggup ditangani.
Mengapa: Ratusan karakter dan efek bertumpuk di satu layar → Akibatnya: Biaya animasi, bayangan, name tag, dan efek naik sebanding dengan jumlah karakter → Di layar: FPS turun 60 → 15 sehingga semua gerakan patah-patah dan input juga terlambat
Gejala: Patah-patah, Input lag · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika paket yang diterima hanya diproses dalam jumlah tertentu per frame, paket yang datang bertumpuk terus terdorong ke frame berikutnya.
Mengapa: Di tempat ramai, ribuan update tiba setiap detik → Akibatnya: Main thread terbentur batas jumlah pemrosesan per frame dan tidak sempat membaca semuanya → Di layar: Gerakan pemain lain makin lama makin terlambat, lalu diterapkan sekaligus
Gejala: Fast forward, Input lag · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika paket server langsung digambar begitu diterima, jitter (variasi selang waktu kedatangan paket) langsung terlihat di layar.
Mengapa: Posisi yang diterima langsung digambar, atau buffer lebih pendek dari jitter → Akibatnya: Berhenti selama paket terlambat, lalu melompat saat paket datang bertumpuk → Di layar: Karakter lain bergerak tersendat-sendat
Gejala: Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Selama paket tidak datang, objek terus ditampilkan bergerak dengan kecepatan terakhir, lalu dikembalikan begitu ketahuan salah.
Mengapa: Paket berhenti diterima, objek terus digerakkan dengan arah dan kecepatan terakhir → Akibatnya: Sebenarnya lawan sudah berhenti atau berbelok → Di layar: Karakter lawan berjalan cukup jauh lalu tiba-tiba pindah ke posisi sebenarnya atau menembus dinding. Jika interval kedatangan paket tidak beraturan, karakter berulang kali melaju ke depan lalu tertarik kembali sehingga bergerak seperti bergetar
Gejala: Teleport, Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Klien Anda menampilkan gerakan lebih dulu, tetapi jika server menghitungnya berbeda, karakter Anda tertarik kembali.
Mengapa: Klien bergerak lebih dulu sebelum konfirmasi server (prediksi) → Akibatnya: Server menghitung collision, kecepatan gerak, atau buff secara berbeda, atau tidak menerima perintahnya → Di layar: Saat konfirmasi datang, karakter Anda tertarik ke belakang
Gejala: Rubber banding · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Setelah sekali berhenti, game menghitung kerja yang tertunda sekaligus, dan perhitungan itu membuatnya tertinggal lagi.
Mengapa: Simulasi game berjalan dengan interval tetap, lalu sekali berhenti → Akibatnya: Step yang tertunda dihitung sekaligus dalam satu frame → Di layar: Frame panjang terjadi beruntun dan melonjak, atau terbentur batas sehingga dunia game melambat
Gejala: Patah-patah, Fast forward, Slow motion · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika waktu server yang diperkirakan klien salah, titik waktu interpolasi dan pengecekan cooldown tidak cocok dengan server.
Mengapa: Waktu server hanya disamakan sekali saat login, lalu dibiarkan meski ping berubah → Akibatnya: Titik waktu interpolasi dan waktu berakhirnya cooldown tidak cocok dengan server → Di layar: Lawan sesekali tersendat, skill ditolak padahal cooldown sudah selesai
Gejala: Patah-patah, Aksi hilang / rollback · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika waktu game disimpan dalam format bilangan desimal berpresisi rendah (float), makin lama game menyala, makin turun resolusi waktunya (selisih waktu terkecil yang bisa dibedakan), sehingga gerakan dan efek bergetar.
Mengapa: Waktu sejak game dinyalakan diakumulasi dalam float atau langsung diteruskan ke shader → Akibatnya: Makin lama game menyala, makin besar selisih terkecil yang bisa dinyatakan float → Di layar: Karakter, animasi, dan efek yang mengalir bergetar hanya di klien yang sudah menyala berhari-hari, lalu normal lagi setelah game dimulai ulang
Gejala: Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Frame yang sudah digambar GPU ditumpuk beberapa buah di antrean, lalu dikirim ke layar mengikuti siklus refresh monitor; selama itu input terlambat.
Mengapa: Driver grafis menumpuk 1–3 frame lebih dulu di antrean → Akibatnya: Input butuh waktu lebih lama sebanyak itu sampai tampil di layar → Di layar: Ping rendah, tetapi kontrol terasa berat dan lamban
Gejala: Input lag, Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Makin lama game menyala, makin besar memori yang dipakai sehingga game makin lambat dan akhirnya tertutup paksa.
Mengapa: Tekstur, UI, dan efek tidak dilepas saat berpindah area bolak-balik → Akibatnya: GC makin sering berjalan dan memori OS kurang sehingga terjadi swap → Di layar: Setelah beberapa jam bermain, game makin patah-patah lalu tertutup paksa (bagi pemain terlihat seperti disconnect)
Gejala: Patah-patah, Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Game tertutup karena error yang tidak tertangani. Bagi pemain ini terlihat seperti disconnect, tetapi server normal.
Mengapa: Null reference, memori kurang, error driver grafis → Akibatnya: Proses game tertutup paksa → Di layar: Laporan “terlempar keluar”. Pada saat yang sama pemain lain baik-baik saja
Gejala: Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Modul keamanan yang berjalan bersama game untuk mencegah cheat melakukan pemeriksaan secara berkala. Jika pemeriksaannya berat atau heartbeat (sinyal berkala yang menandakan klien masih hidup) ke server keamanan terlambat, game menjadi patah-patah atau disconnect.
Mengapa: Modul keamanan secara berkala memeriksa memori game, program yang sedang berjalan, dan driver → Akibatnya: Selama pemeriksaan, thread game berhenti, atau heartbeat tidak terkirim tepat waktu → Di layar: Tersendat sesaat dengan interval tetap; jika parah, disconnect disertai pesan error keamanan
Gejala: Patah-patah, Freeze, Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Di Windows, Android, dan iOS, game berbagi CPU, memori, dan jaringan dengan program lain. Lag terjadi saat sistem operasi terlambat memberi jatah CPU ke game, menurunkan kecepatan untuk menghemat baterai, atau menangguhkan aplikasi di latar belakang.
Di sistem operasi (OS), scheduler (fungsi yang menentukan giliran memakai CPU) membagi waktu CPU ke banyak program. Game, antivirus, browser, dan program update semuanya menunggu “giliran saya”, dan OS memberi jatah core secara bergantian per beberapa ms hingga puluhan ms (time slice). OS memang memberi prioritas sedikit lebih tinggi pada game yang tampil di depan (foreground), tetapi jika pekerjaan lebih banyak daripada jumlah core, game pun harus menunggu, dan penantian itu memperlambat frame.
Jaringan juga melewati OS. Paket yang diterima kartu LAN atau chip Wi-Fi ditampung di buffer terima milik driver dan OS, lalu menunggu sampai game mengambilnya. Jika game terlalu sibuk dan terlambat mengambilnya, buffer meluap; jika diambil sekaligus, terjadi fast forward. Di perangkat mobile, ada hal yang sangat penting: demi baterai, OS mengalihkan koneksi nirkabel ke mode hemat daya dan juga sering menangguhkan aplikasinya sendiri.
OS adalah kepala koki yang mengatur banyak koki agar bergantian memakai satu-satunya dapur. Meskipun game sedang memasak hidangan yang mendesak, ia harus menunggu jika koki bernama pemindaian antivirus menguasai kompor. Jika dapur terlalu panas (perangkat panas), api pun dikecilkan.
Saat pemindaian antivirus, Windows Update, program streaming, atau video di browser memakai core CPU, thread game tidak mendapat jatah CPU dan harus menunggu.
Mengapa: Program lain memakai core CPU dalam waktu lama → Akibatnya: Thread game menunggu jatah CPU → Di layar: Frame terlambat dan pemrosesan paket yang diterima juga terlambat
Gejala: Patah-patah, Fast forward · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Mode baterai laptop, mode hemat daya ponsel, dan panas perangkat menurunkan kecepatan CPU dan GPU. Ciri penurunan karena panas: awalnya normal, lalu baru melambat setelah cukup lama.
Mengapa: Mode baterai atau hemat daya aktif, atau perangkat menjadi panas → Akibatnya: Clock CPU dan GPU diturunkan 30–50%, tergantung perangkat → Di layar: Dengan mode hemat daya, FPS turun dan game patah-patah sejak awal; karena panas, setelah bermain beberapa menit hingga sekitar 20 menit
Gejala: Patah-patah, Input lag · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Timer default Windows bekerja dalam satuan 15,6 ms, sehingga “tidur 1 ms saja” sebenarnya memanjang sampai siklus timer berikutnya, paling lama 15,6 ms.
Mengapa: Batas frame dan pengiriman paket diimplementasikan dengan Sleep (menunggu sebentar) → Akibatnya: OS hanya membangunkan thread dalam satuan 15,6 ms → Di layar: Interval frame dan interval pengiriman input tidak beraturan
Gejala: Patah-patah · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika Anda keluar sebentar dari game untuk melihat notifikasi, OS menangguhkan aplikasi (suspend) beberapa detik kemudian, dan selama itu server memutus koneksi Anda.
Mengapa: Keluar sebentar dari game untuk membaca pesan atau menerima telepon → Akibatnya: Engine game menghentikan jalannya game, dan OS pun segera menghentikan aplikasi dan jaringannya → Di layar: Saat kembali, sudah disconnect dan harus reconnect
Gejala: Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Saat Anda keluar rumah, Wi-Fi terputus dan beralih ke LTE/5G sehingga alamat IP Anda berubah dan koneksi yang ada menjadi tidak berlaku.
Mengapa: Sinyal Wi-Fi melemah sehingga beralih ke jaringan seluler → Akibatnya: Alamat IP Anda berubah sehingga koneksi yang dibuat dengan alamat lama tidak bisa dipakai lagi → Di layar: Berhenti sejenak, lalu disconnect atau reconnect
Gejala: Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Jika antivirus atau firewall memeriksa semua paket, latensi bertambah, dan jika berlebihan, game salah dikira serangan lalu diblokir.
Mengapa: Program keamanan memeriksa satu per satu setiap paket yang dikirim dan diterima → Akibatnya: Setiap paket mendapat tambahan latensi, dan jika pemeriksaan tertinggal, paket dibuang → Di layar: Ping melonjak tidak beraturan atau koneksi diblokir
Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika game terlalu sibuk sehingga terlambat mengambil paket dari socket (antarmuka kirim-terima jaringan yang disediakan OS), buffer OS meluap.
Mengapa: Frame tertunda sehingga game terlambat membaca socket → Akibatnya: Buffer terima OS penuh: UDP membuang paket, TCP mengecilkan receive window sehingga pengirim berhenti mengirim → Di layar: Teleport (UDP) atau fast forward (TCP)
Gejala: Teleport, Fast forward · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Jika puluhan tab browser dan game menyala bersamaan, OS memindahkan sebagian memori game ke disk.
Mengapa: RAM total tidak cukup → Akibatnya: OS memindahkan memori game yang tidak sedang dipakai ke disk → Di layar: Saat bagian itu dipakai lagi, game berhenti puluhan hingga ratusan ms, tergantung storage
Gejala: Freeze, Patah-patah · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika memori yang dibutuhkan opsi grafis lebih besar dari memori kartu grafis, OS memindahkan tekstur ke memori PC lalu mengambilnya kembali sehingga game patah-patah.
Mengapa: Opsi tekstur tinggi serta beragam equipment dan efek di tempat ramai membuat memori kartu grafis penuh → Akibatnya: OS memindahkan tekstur yang tidak sedang dipakai ke memori PC, lalu mengambilnya kembali lewat bus PCIe yang lambat saat dibutuhkan → Di layar: Tersendat sesaat setiap kali adegan atau karakter baru terlihat, tekstur buram untuk sementara
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Selama OS berpindah-pindah channel secara berkala untuk mencari Wi-Fi di sekitar, komunikasi berhenti sejenak.
Mengapa: OS atau driver mencari Wi-Fi di sekitar secara berkala → Akibatnya: Kirim-terima berhenti sejenak selama pencarian → Di layar: Ping melonjak dengan interval yang sangat teratur (misalnya setiap 60 detik)
Gejala: Patah-patah, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika kartu LAN atau chip Wi-Fi masuk ke mode hemat daya di antara paket, butuh waktu untuk aktif kembali.
Mengapa: Fitur hemat daya perangkat jaringan aktif atau driver sudah usang → Akibatnya: Jeda saat bangun (wake-up), sesekali perangkat dimulai ulang → Di layar: Latensi tidak beraturan, dalam kasus yang jarang berhenti beberapa detik
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika sinkronisasi cloud, unduhan besar, atau patch game berjalan di PC yang sama, paket game harus menunggu di antrean.
Mengapa: Aplikasi lain memakai upload dan download secara maksimal → Akibatnya: Paket game menumpuk di antrean PC dan router → Di layar: Ping melonjak drastis, input lag, fast forward
Gejala: Input lag, Fast forward · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Saat Anda melihat jendela lain atau meminimalkan game, game dan Windows menjalankan game lebih lambat untuk menghemat daya. Saat kembali, paket yang tertunda datang sekaligus, atau koneksi sudah terputus.
Mengapa: Beralih ke jendela lain dengan Alt+Tab atau meminimalkan game → Akibatnya: Selama game tidak terlihat, FPS diturunkan drastis atau game dihentikan, dan Windows juga menurunkan prioritas program yang tidak terlihat → Di layar: Fast forward saat kembali; jika lama diminimalkan, disconnect
Gejala: Fast forward, Patah-patah, Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Program messenger, launcher, perekam, dan penampil FPS menyusup ke proses rendering game (hooking) untuk menggambar UI mereka di atas layar game. Pekerjaan setiap frame bertambah, dan sesekali program itu bentrok dengan game sehingga game tersendat sesaat atau tertutup paksa.
Mengapa: Overlay dari messenger, launcher game, tools kartu grafis, atau program perekam aktif → Akibatnya: Setiap kali frame dikirim ke layar, overlay menyela untuk menggambar UI-nya → Di layar: Frame sedikit demi sedikit terlambat, dan saat notifikasi muncul game tersendat sesaat, mengalami error grafis, atau tertutup paksa (bagi pemain terlihat seperti disconnect)
Gejala: Patah-patah, Freeze, Disconnect · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika ping normal tetapi kontrol terasa berat, pemrosesan gambar di TV, controller nirkabel, atau fitur frame generation mungkin menambah latensi antara input dan layar.
Mengapa: Mode game TV mati, memakai controller Bluetooth atau nirkabel, atau frame generation (frame generation DLSS/FSR) aktif → Akibatnya: TV mengeluarkan frame lebih lambat selama memproses kualitas gambar, input nirkabel tiba terlambat sebesar siklus pengiriman dan interferensi, dan frame generation menunggu frame berikutnya untuk membuat frame sisipan → Di layar: Angka ping dan FPS bagus, tetapi ada jeda antara tombol ditekan dan hasilnya tampil di layar: input lag
Gejala: Input lag · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Inilah beberapa meter terakhir sebelum paket meninggalkan rumah. Jaraknya pendek, tetapi cukup banyak laporan lag berasal dari sini. Penyebabnya, di Wi-Fi banyak perangkat berbagi channel nirkabel yang sama, dan router mengirim trafik seluruh keluarga lewat satu antrean.
Wi-Fi berbagi channel nirkabel (pita frekuensi) yang sama dengan router tetangga, dan pita 2,4 GHz juga bertumpang tindih dengan Bluetooth dan microwave. Jika terjadi tabrakan saat mengirim, perangkat berhenti sejenak lalu mengirim ulang. Jika pengiriman ulang ini menumpuk, paket tiba tidak beraturan. Rata-rata ping terlihat baik, tetapi sering melonjak sesaat: itulah ciri khas Wi-Fi.
Router adalah perangkat yang wajib dilewati semua perangkat di rumah untuk keluar ke internet. Jika data yang dikirim melebihi kecepatan yang sanggup diterima koneksi internet, terbentuk antrean di dalam router atau modem. Perangkat tanpa fitur manajemen antrean (SQM) membiarkan antrean ini memanjang hingga setara ratusan ms. Router mahal pun sama saja jika fitur ini dimatikan. Saat adik Anda mengunggah video, paket game ikut menunggu di ujung belakang antrean itu. Fenomena ini disebut bufferbloat.
Router juga mencatat koneksi “perangkat di dalam ↔ server di luar” di tabel NAT, lalu menghapusnya dari tabel jika selama beberapa waktu tidak ada paket yang lewat. Inilah penyebab umum pemain disconnect setelah lama diam. Pada jaringan seluler, masih ditambah perpindahan BTS, mode hemat daya nirkabel, dan sinyal lemah.
Router adalah satu-satunya gerbang keluar-masuk sebuah kompleks apartemen. Jika truk pindahan (unggahan video) berbaris, kurir motor yang sedang buru-buru (paket game) pun harus menunggu di belakang truk. Router yang cerdas (SQM) membuka jalur khusus untuk kurir.
Jika sinyal lemah atau ada interferensi, paket dikirim ulang beberapa kali di jalur nirkabel sehingga waktu kedatangannya tidak beraturan.
Mengapa: Kualitas sinyal turun karena dinding, jarak, microwave, Bluetooth, atau router tetangga → Akibatnya: Pengiriman gagal di jalur nirkabel → dikirim ulang beberapa kali → Di layar: Kedatangan paket tidak beraturan (jitter) sehingga karakter tersendat-sendat; jika parah, packet loss membuat karakter teleport
Gejala: Patah-patah, Teleport, Rubber banding · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Di tempat dengan puluhan router seperti apartemen, router harus berbagi channel yang sama sehingga harus menunggu kesempatan mengirim.
Mengapa: Puluhan router memakai channel 2,4 GHz yang sama → Akibatnya: Untuk mengirim, harus menunggu sampai perangkat lain selesai mengirim dan channel kosong → Di layar: Pada malam hari saat orang-orang pulang ke rumah, jitter (variasi selang waktu kedatangan paket) bertambah sehingga game patah-patah
Gejala: Patah-patah, Input lag · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Saat anggota keluarga mengunggah video atau mengunduh file besar, paket senilai ratusan ms menumpuk di antrean router, dan paket game pun menunggu di belakangnya.
Mengapa: Koneksi penuh karena upload video atau backup cloud oleh keluarga, live streaming yang Anda siarkan, atau unduhan besar → Akibatnya: Router atau modem menyimpan paket yang meluap di antrean yang besar → Di layar: Paket game juga menunggu di belakang antrean sehingga ping melonjak hingga ratusan ms
Gejala: Input lag, Fast forward, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Router menghapus koneksi idle yang lama tidak dilewati paket dari tabel NAT. Ini penyebab umum disconnect tepat saat pemain mulai bergerak setelah lama diam.
Mengapa: Router mencatat koneksi “perangkat di dalam ↔ server di luar” di tabel NAT (tabel translasi alamat) → Akibatnya: Jika lama tidak ada paket, entri dihapus dari tabel (untuk UDP umumnya 30–120 detik) → Di layar: Paket dari server tidak bisa masuk ke dalam rumah sehingga terjadi disconnect
Gejala: Disconnect · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika puluhan perangkat dan ribuan koneksi membebani router murah, router itu sendiri tidak sanggup memprosesnya.
Mengapa: Puluhan perangkat serta P2P dan torrent membuka ribuan koneksi → Akibatnya: CPU dan tabel sesi router penuh → Di layar: Pemrosesan paket terlambat dan paket hilang, koneksi baru gagal
Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti, Disconnect · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)
Saat bepergian dengan bus atau kereta bawah tanah, komunikasi terputus selama BTS berganti.
Mengapa: BTS yang tersambung berganti saat bergerak → Akibatnya: Biasanya hanya jeda puluhan ms, tetapi jika sinyal buruk dan perpindahan gagal, koneksi bisa putus ratusan ms hingga beberapa detik → Di layar: Berhenti lalu teleport; jika lama, disconnect
Gejala: Freeze, Teleport, Disconnect · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Jika lama tidak ada komunikasi, ponsel menurunkan koneksi radio ke status daya rendah, lalu harus menaikkannya lagi saat paket berikutnya sehingga terlambat.
Mengapa: Jika sebentar saja tidak ada komunikasi, ponsel mengalihkan koneksi radio ke mode hemat daya → Akibatnya: Untuk mengirim paket berikutnya, koneksi harus dinaikkan lagi → Di layar: Hanya aksi pertama setelah diam yang terasa sangat terlambat
Gejala: Input lag · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game)
Di lift, ruang bawah tanah, atau bagian dalam gedung, retransmisi bertambah, kecepatan turun, dan akhirnya terjadi disconnect.
Mengapa: Berpindah ke tempat dengan sinyal lemah → Akibatnya: Retransmisi radio bertambah, kecepatan turun, koneksi putus sesaat → Di layar: Jitter dan packet loss menyebabkan patah-patah dan teleport, akhirnya disconnect
Gejala: Patah-patah, Teleport, Disconnect · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Di dalam gedung dengan sinyal 5G lemah atau di tepi jangkauan 5G, ponsel sering berpindah antara 5G dan LTE, dan setiap kali berpindah ping melonjak atau komunikasi terputus sejenak.
Mengapa: Berada di tempat dengan sinyal 5G yang naik turun (dalam gedung, tepi jangkauan 5G) → Akibatnya: Ponsel sering berpindah antara 5G dan LTE, dan setiap kali itu muncul jeda singkat → Di layar: Ping melonjak tanpa pola walau diam, sesekali freeze atau teleport
Gejala: Patah-patah, Teleport, Freeze · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Halaman login Wi-Fi kafe atau firewall kantor memblokir koneksi game.
Mengapa: Belum lolos autentikasi di halaman login, atau firewall memblokir port game dan UDP → Akibatnya: Upaya koneksi itu sendiri diblokir, atau hanya sebagian yang lolos → Di layar: Tidak bisa masuk; login berhasil, tetapi gagal masuk ke game
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Setelah meninggalkan rumah, paket melewati jaringan ISP, titik sambungan antar-ISP, dan kadang kabel bawah laut, sampai tiba di data center tempat server berada. Latensi di jalur ini sebagian besar ditentukan oleh jarak dan pemilihan rute (routing), dan sering kali tidak bisa diperbaiki langsung oleh perusahaan game.
Di dalam kabel serat optik, cahaya merambat sekitar 200.000 km per detik. Untuk server sejauh 1.000 km, pulang-pergi butuh minimal 10 ms, dan selama memakai kabel serat optik, angka ini tidak bisa dikurangi sebagus apa pun server atau perangkatnya. Paket sebenarnya tidak berjalan lurus. Paket memutar mengikuti titik sambungan antar-ISP (peering), sehingga biasanya butuh 1,5–2 kali nilai teoretis. Untuk rute seperti Korea–Eropa yang hampir tidak punya kabel besar di sepanjang garis lurusnya, paket memutar lewat Asia Tenggara dan Suez atau lewat Amerika sehingga menjadi 2,5–3 kali (pulang-pergi sekitar 230–270 ms).
Masalahnya, rute ini berubah menurut waktu dan situasi. Sekitar pukul 21.00–23.00, titik sambungan antar-ISP mudah padat karena semua orang menonton video. Saat informasi rute (BGP) berubah, paket tidak bisa mencapai tujuan selama beberapa detik hingga puluhan detik (dalam kasus yang jarang, sampai beberapa menit). Jika kabel bawah laut putus, trafik memutar lewat rute jauh selama berminggu-minggu. Jika lag hanya terjadi pada “pelanggan ISP tertentu”, “malam hari saja”, atau “dari luar negeri saja”, curigai lapisan ini lebih dulu.
Jaringan ISP adalah jaringan jalan tol. Perjalanan dari Seoul ke Busan tetap butuh waktu sesuai jaraknya meskipun jalan lancar, gerbang tol (titik peering) macet saat jam pulang kerja, dan jika terjadi kecelakaan, aplikasi navigasi mengarahkan ke jalan memutar yang jauh.
Di kabel serat optik, cahaya pun hanya menempuh sekitar 200.000 km per detik. Server yang jauh tetap lambat, sebagus apa pun servernya.
Mengapa: Server berada jauh (server luar negeri, benua lain) → Akibatnya: Waktu pulang-pergi bertambah sebanding dengan jarak (minimal 10 ms per 1.000 km) → Di layar: Input lag yang tetap di setiap aksi, pemain dirugikan dalam keputusan server
Gejala: Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Pada internet satelit, sinyal harus bolak-balik ke luar angkasa. Dengan satelit geostasioner, pulang-pergi saja sudah lebih dari 0,5 detik. Satelit orbit rendah seperti Starlink biasanya cepat, tetapi saat rute dialokasikan ulang, latensinya berfluktuasi dan koneksi kadang putus sesaat.
Mengapa: Terhubung dari rumah, kapal, atau pesawat lewat internet satelit geostasioner atau orbit rendah, atau lewat Wi-Fi pesawat yang memakai satelit → Akibatnya: Satelit geostasioner berada di ketinggian sekitar 36.000 km sehingga jarak tempuhnya memang panjang; satelit orbit rendah mengalokasikan ulang rute terminal, satelit, dan stasiun bumi dalam siklus pendek, dan pada saat itu muncul latensi dan packet loss sesaat → Di layar: Geostasioner: input lag besar di setiap aksi. Orbit rendah: biasanya normal, tetapi secara berkala terjadi patah-patah atau teleport
Gejala: Input lag, Patah-patah, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Karena kontrak interkoneksi antar-ISP, rute ke server yang dekat pun bisa memutar lewat tempat yang jauh.
Mengapa: ISP Anda dan ISP di sisi server tidak terhubung langsung → Akibatnya: Rute melewati negara atau kota lain sehingga jarak dan jumlah perangkat yang dilewati bertambah → Di layar: Hanya pelanggan ISP tertentu yang ping-nya sangat tinggi
Gejala: Input lag · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Sekitar pukul 21.00–23.00, trafik video melonjak sehingga jalur interkoneksi antar-ISP (peering) mudah padat.
Mengapa: Streaming dan unduhan menumpuk pada malam hari → Akibatnya: Terjadi antrean dan packet loss di jalur peering → Di layar: Hanya pada malam hari, pelanggan ISP tertentu mengalami patah-patah atau teleport
Gejala: Patah-patah, Teleport, Rubber banding · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Jika kabel bawah laut putus, trafik harus memutar lewat rute yang jauh selama beberapa minggu (jika lama, beberapa bulan) sampai kabel diperbaiki, dan jalur yang tersisa menjadi padat.
Mengapa: Kabel putus atau perangkat rusak → Akibatnya: Trafik menumpuk di rute memutar yang jauh dan di jalur yang tersisa → Di layar: Ping pemain dari luar negeri melonjak dan packet loss berlangsung beberapa hari hingga beberapa minggu
Gejala: Input lag, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Saat informasi rute internet berubah, paket hilang selama beberapa detik hingga puluhan detik (dalam kasus yang jarang, sampai beberapa menit) sampai rute kembali konvergen.
Mengapa: Informasi rute di segmen salah satu ISP berubah → Akibatnya: Selama beberapa detik hingga puluhan detik, paket hilang atau dialihkan ke rute baru → Di layar: Tiba-tiba freeze beberapa detik, lalu angka ping berubah (misalnya 40 → 70 ms)
Gejala: Freeze, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
ISP dan data center menyiapkan beberapa jalur ke tujuan yang sama dan menetapkan satu jalur untuk setiap koneksi. Jika hanya satu jalur yang rusak, hanya pemain yang mendapat jalur itu yang terus mengalami lag.
Mengapa: Di segmen yang menggabungkan beberapa jalur, satu jalur atau satu perangkat rusak atau padat → Akibatnya: Jalur ditentukan dari kombinasi alamat dan port (hash), sehingga hanya koneksi yang mendapat jalur itu yang mengalami packet loss dan latensi → Di layar: Di wilayah dan ISP yang sama, hanya sebagian pemain yang terus-menerus teleport. Kadang normal kembali setelah reconnect
Gejala: Teleport, Rubber banding, Patah-patah · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Jika kuota data terlampaui atau layanan internet mengelola trafik tertentu, paket ditunda atau dibuang.
Mengapa: Kecepatan dibatasi setelah kuota data habis, atau trafik tertentu dibatasi → Akibatnya: Paket menunggu di antrean atau dibuang → Di layar: Lag setelah pemakaian tertentu, terutama di seluler
Gejala: Input lag, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Sebagian jaringan memblokir alamat dan port UDP tertentu atau membatasi kecepatan UDP, dan perangkat inspeksi paket menyaring protokol yang tidak dikenalinya. Game yang berkomunikasi lewat UDP tidak bisa tersambung atau sering terputus di jaringan itu.
Mengapa: Terhubung dari jaringan ISP yang membatasi kecepatan UDP, atau dari jaringan yang memiliki perangkat inspeksi trafik (sensor) di tingkat negara atau ISP → Akibatnya: Memblokir alamat dan port UDP tertentu, membatasi kecepatan UDP pada jam ramai, menyaring port dan protokol yang tidak ada di allowlist, atau hanya meloloskan beberapa paket pertama lalu memblokir → Di layar: Hanya pemain dari negara atau ISP tertentu yang tidak bisa masuk atau mengalami loading tanpa henti, disconnect tak lama setelah tersambung, atau teleport karena packet loss pada jam ramai
Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect, Teleport · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Konektor yang kontaknya buruk, kabel yang sudah tua, atau modem yang bermasalah menimbulkan packet loss terus-menerus dan koneksi yang putus secara berkala.
Mengapa: Kabel rusak, kontak buruk, modem atau ONT bermasalah → Akibatnya: Paket dibuang karena bit error; sesekali koneksi terputus beberapa detik hingga sekitar 1 menit karena sedang tersambung ulang → Di layar: Packet loss kecil yang terus-menerus, sesekali freeze beberapa detik atau disconnect
Gejala: Teleport, Freeze, Disconnect · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal)
Jika DNS, yang menerjemahkan nama server menjadi alamat, lambat atau gagal, server login dan server patch tidak bisa ditemukan.
Mengapa: DNS ISP mengalami gangguan atau salah konfigurasi → Akibatnya: Alamat server login dan server patch tidak ditemukan → Di layar: Menunggu lama setelah menekan tombol masuk, atau tidak bisa masuk. Pemain yang sudah tersambung tetap normal
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Serangan besar yang ditujukan ke perusahaan game atau ke pihak lain di jaringan yang sama memenuhi jalur bersama.
Mengapa: Muncul trafik serangan dalam jumlah besar → Akibatnya: Trafik normal yang memakai jalur yang sama ikut tertahan dan dibuang → Di layar: Banyak pemain sekaligus mengalami teleport, disconnect, atau tidak bisa masuk
Gejala: Teleport, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Jaringan seluler dan sebagian ISP membuat banyak pelanggan berbagi satu IP, dan mapping koneksi idle dihapus dalam waktu singkat.
Mengapa: Perangkat ISP mengelola tabel sesi untuk banyak sekali pelanggan → Akibatnya: Batas tabel sesi, idle timeout yang pendek → Di layar: Disconnect setelah lama diam, false positive yang memblokir sekaligus semua orang yang memakai IP yang sama
Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan klien (Tim Pengembang Game) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur)
Jika VPN atau game booster diaktifkan, paket melewati server relay milik perusahaan itu. Jika server relay jauh atau padat, koneksi malah menjadi lebih lambat.
Mengapa: VPN atau game booster mengalihkan semua paket game ke server relay → Akibatnya: Jarak dan kongesti sampai server relay ikut bertambah, dan header tunnel juga mengurangi MTU (ukuran paket yang bisa dikirim sekaligus) → Di layar: Ping naik dan packet loss, atau tidak bisa masuk karena ikut diblokir bersama orang lain yang memakai alamat relay yang sama
Gejala: Input lag, Teleport, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Tepat sebelum sampai ke server, paket melewati router, perangkat proteksi DDoS, firewall, load balancer, dan switch secara berurutan. Biasanya jalur ini memakan waktu kurang dari 1 ms, tetapi jika satu perangkat saja penuh kapasitasnya atau mengalami gangguan, ribuan pemain di seluruh server terdampak bersamaan.
Setiap perangkat punya peran berbeda. Router menentukan rute, perangkat proteksi DDoS menyaring trafik serangan, dan firewall hanya meloloskan koneksi yang diizinkan sambil melacak semua koneksi di tabel sesi. Load balancer membagi koneksi yang masuk ke beberapa server, dan switch menghubungkan server satu sama lain.
Kelemahan bersama perangkat-perangkat ini adalah ukuran tabel dan ukuran buffer. Jika tabel sesi firewall penuh, koneksi baru tidak bisa diterima. Load balancer menghapus koneksi idle setelah waktu tertentu. Buffer switch yang kecil meluap dalam waktu kurang dari 1 ms saat beberapa server mengirim paket ke ribuan pemain pada saat yang sama (misalnya saat world boss muncul). Lalu, saat satu perangkat rusak dan dialihkan ke perangkat cadangan (failover), game berhenti bagi semua pemain selama beberapa detik.
Pintu masuk data center adalah pemeriksaan keamanan dan gerbang keberangkatan bandara. Petugas pemeriksaan (firewall) hanya meloloskan orang yang ada di daftar, dan jika kolom daftar sudah penuh, tidak ada lagi yang bisa diterima. Petugas gerbang (load balancer) menganggap penumpang yang lama duduk diam sebagai “orang yang sudah pergi” dan mencoretnya dari daftar.
Firewall mencatat dan melacak setiap koneksi yang diloloskannya di tabel sesi. Jika tabelnya penuh, koneksi baru tidak bisa diterima.
Mengapa: Jumlah sesi mencapai batas karena lonjakan koneksi atau serangan → Akibatnya: Koneksi baru ditolak karena tidak ada entri kosong untuk mencatatnya → Di layar: Pemain yang baru mau masuk tidak bisa masuk atau mengalami loading tanpa henti, dan sebagian koneksi yang sudah ada juga disconnect
Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Saat trafik dialihkan ke scrubbing center untuk menangkal serangan, rutenya menjadi lebih panjang, dan pemain yang normal kadang salah dikira serangan lalu diblokir.
Mengapa: Setelah serangan terdeteksi (atau terus-menerus), trafik masuk dialihkan ke scrubbing center → Akibatnya: Rute bertambah panjang, dan sebagian paket normal dinilai sebagai serangan → Di layar: Ping semua pemain naik, hanya wilayah atau ISP tertentu yang tidak bisa masuk
Gejala: Input lag, Tidak bisa masuk / loading tanpa henti, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Load balancer menghapus koneksi idle setelah waktu tertentu. Game masih menganggap koneksinya tersambung, lalu pemain disconnect.
Mengapa: Pemain tidak mengirim paket apa pun selama beberapa waktu (membuka jendela dialog, AFK) → Akibatnya: Load balancer membersihkan koneksi idle (nilai default umum 60–350 detik) → Di layar: Disconnect tepat saat pemain mulai bergerak lagi
Gejala: Disconnect · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Firewall yang terpasang di server cloud (security group) juga melacak koneksi, dan entri pelacakan untuk koneksi idle kedaluwarsa setelah waktu tertentu. Server yang tersambung langsung tanpa load balancer pun bisa membuat pemain yang lama diam terputus.
Mengapa: Konfigurasi yang membuat security group melacak koneksi game (hanya mengizinkan alamat tertentu, membatasi aturan outbound, lewat NLB, dan sebagainya) → Akibatnya: Entri pelacakan untuk koneksi yang idle cukup lama kedaluwarsa, lalu security group membuang diam-diam paket yang datang sesudahnya → Di layar: Setelah AFK, pemain bergerak lagi tetapi tidak ada respons, lalu disconnect. Program server baru menyadarinya lama kemudian
Gejala: Disconnect · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game)
Koneksi dari server di subnet privat ke luar (autentikasi platform, pembayaran, API eksternal) dikirim keluar oleh NAT gateway setelah alamat dan portnya diganti. Jika koneksi bersamaan ke tujuan yang sama melebihi batas port gateway, koneksi baru gagal.
Mengapa: Server-server membuka banyak koneksi singkat ke alamat eksternal yang sama, seperti autentikasi platform atau pembayaran, atau membiarkan koneksi terbuka lama → Akibatnya: NAT gateway tidak bisa lagi mengalokasikan port sumber untuk tujuan itu sehingga koneksi baru gagal → Di layar: Di dalam game normal, tetapi hanya fitur yang memanggil layanan eksternal seperti login, pembayaran, dan pemberian hadiah yang gagal atau lambat (tidak bisa masuk / loading tanpa henti, aksi hilang / rollback)
Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Koneksi menumpuk di satu server saja, atau pemain terus dikirim ke server yang sudah mati.
Mengapa: Aturan distribusi tidak sesuai, atau health check tidak melihat kondisi sebenarnya → Akibatnya: Hanya satu server yang kelebihan beban, atau ada percobaan koneksi ke server yang sudah mati → Di layar: Hanya sebagian channel atau sebagian pemain yang mengalami slow motion, tidak bisa masuk, atau loading tanpa henti
Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika beberapa server sekaligus mengirim paket ke ribuan pemain pada saat yang sama, buffer kecil di port switch tempat trafik itu bertemu meluap dalam waktu kurang dari 1 ms.
Mengapa: Kemunculan world boss, skill berskala besar, atau tick beberapa server yang bertepatan di saat yang sama membuat pengiriman terjadi sekaligus → Akibatnya: Buffer (ratusan KB hingga beberapa MB per port) di titik tempat beberapa port bertemu di satu port, atau tempat trafik pindah dari port cepat ke port lambat, penuh sesaat → Di layar: Sebagian paket dibuang, banyak pemain sekaligus mengalami teleport atau skill tidak keluar
Gejala: Teleport, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur)
Jika deploy patch, pengiriman log, dan backup memakai jalur yang sama dengan game, jalurnya penuh.
Mengapa: Transfer besar memakai jalur yang sama → Akibatnya: Antrean dan packet loss di jalur bertambah → Di layar: Ping seluruh server naik dan pemain teleport
Gejala: Input lag, Teleport · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Saat satu router atau firewall rusak dan dialihkan ke perangkat cadangan (failover), semua pemain mengalami freeze selama beberapa detik.
Mengapa: Dialihkan ke perangkat cadangan karena perangkat rusak atau maintenance → Akibatnya: Peralihan memakan waktu beberapa detik, dan jika informasi sesi tidak tersinkronisasi, koneksi di-reset → Di layar: Semua pemain di server mengalami freeze bersamaan, disconnect massal
Gejala: Freeze, Disconnect · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Jika modul optik atau kabel rusak, sebagian paket yang lewat jalur itu rusak dengan persentase tertentu.
Mengapa: Bit error karena modul optik atau kabel rusak → Akibatnya: Paket yang rusak dibuang diam-diam oleh perangkat → Di layar: Hanya sebagian server dan pemain yang memakai jalur itu yang terus mengalami packet loss sehingga terjadi teleport atau rubber banding
Gejala: Teleport, Rubber banding · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur)
Jika MTU (ukuran yang bisa dikirim sekaligus) di segmen tengah mengecil tetapi notifikasi ukuran terlampaui diblokir, hanya paket besar yang terus hilang.
Mengapa: MTU mengecil di segmen tunnel atau VPN → Akibatnya: Notifikasi ukuran terlampaui (ICMP) diblokir firewall sehingga pengirim tidak tahu → Di layar: Freeze hanya saat membuka layar besar seperti inventory atau daftar karakter, lalu disconnect
Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Kartu jaringan yang terpasang di server menerima ratusan ribu hingga jutaan paket per detik dan meneruskannya ke CPU. Jika pemrosesan di sini tertinggal, paket hilang tanpa program server tahu bahwa paket itu pernah datang.
NIC menampung paket yang tiba secara berurutan di ring buffer (buffer terima yang memakai ulang slot berjumlah tetap secara bergiliran), lalu memberi tahu CPU bahwa “ada paket masuk” (interrupt). CPU mengambil paket dari ring buffer dan meneruskannya ke OS. Jika paket masuk lebih cepat daripada CPU mengambilnya, semua slot penuh dan paket yang datang sesudahnya dibuang. Hanya angka di statistik kartu jaringan (ethtool -S) yang diam-diam naik, sementara log server game tidak mencatat error apa pun, sehingga lag ini sulit ditemukan.
NIC modern punya fitur yang menyediakan beberapa antrean terima (ring buffer) dan membagi notifikasinya ke beberapa core CPU (RSS). Namun, jika fitur ini tidak dikonfigurasi atau trafik terpusat ke satu antrean, hanya satu core yang mencapai 100% dan menjadi bottleneck. Di server cloud, ada lagi batas paket per detik, bandwidth, dan jumlah koneksi di depan NIC, dan kelebihannya dibuang sebelum sampai ke server. Hal ini tidak terlihat di metrik biasa seperti CPU atau ring buffer. Di AWS, jejaknya hanya ada di statistik driver ENA (pps_allowance_exceeded pada ethtool -S dan lainnya).
NIC adalah kotak surat apartemen, ring buffer adalah jumlah lubang kotak surat, dan interrupt adalah bel pintu yang ditekan tukang pos. Jika surat terus berdatangan tetapi hanya satu orang yang mengambilnya, lubangnya penuh dan surat jatuh ke lantai. RSS berarti menugaskan beberapa orang untuk mengambil surat.
Jika NIC hanya mengirim interrupt kedatangan paket ke satu core CPU, core itu menjadi bottleneck.
Mengapa: Hanya ada satu antrean terima (RX queue), atau RSS, yang menyebar paket ke beberapa core, dimatikan → Akibatnya: Satu core mencapai 100% sehingga paket tidak diambil tepat waktu → Di layar: Saat pemain berkumpul, terjadi packet loss dan latensi di seluruh server (teleport, input lag)
Gejala: Teleport, Rubber banding, Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Jika ring buffer, tempat NIC menampung paket sementara, terlalu kecil, buffer meluap saat paket datang serentak dan paket dibuang.
Mengapa: Ring buffer kecil karena masih memakai nilai default (256–2.048 slot, tergantung driver) → Akibatnya: Saat burst, buffer meluap sebelum CPU sempat mengambil paket → Di layar: Packet loss hanya pada saat burst (teleport, skill tidak keluar). Tidak ada jejak di log server game
Gejala: Teleport, Aksi hilang / rollback · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Jika NIC mengumpulkan paket lalu memberi tahu CPU sekaligus untuk mengurangi beban CPU, paket terlambat selama waktu pengumpulan itu.
Mengapa: NIC mengumpulkan paket selama waktu atau jumlah tertentu lalu memberi tahu CPU → Akibatnya: Paket menunggu selama dikumpulkan → Di layar: Latensi bertambah sedikit. Biasanya kecil, tetapi jika berlebihan bisa mencapai skala ms
Gejala: Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Server cloud memiliki batas jumlah paket per detik dan bandwidth per tipe instance, dan jika terlampaui, paket dibuang diam-diam.
Mengapa: Jumlah pemain online bersamaan bertambah sehingga jumlah paket per detik melewati batas instance → Akibatnya: Jaringan cloud membuang kelebihannya → Di layar: Teleport dan skill tidak keluar karena packet loss yang penyebabnya tidak jelas. CPU server masih longgar
Gejala: Teleport, Aksi hilang / rollback · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Jika kartu 1 Gbps atau 10 Gbps dipakai sampai batasnya, antrean kirim memanjang dan akhirnya paket dibuang.
Mengapa: Broadcast bertambah sehingga volume kirim mencapai batas kartu → Akibatnya: Antrean kirim memanjang, dan jika meluap, paket dibuang → Di layar: Latensi dan packet loss di seluruh server (input lag, teleport)
Gejala: Input lag, Teleport · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika virtual machine lain di server fisik yang sama banyak memakai jaringan atau CPU, pemrosesan di server Anda tertunda secara tidak beraturan.
Mengapa: Virtual machine lain di server fisik yang sama banyak memakai sumber daya → Akibatnya: Pemrosesan paket di virtual machine Anda tertunda secara tidak beraturan → Di layar: Tanpa penyebab yang jelas, sesekali muncul jitter (variasi selang waktu kedatangan paket) sehingga game patah-patah
Gejala: Patah-patah · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Saat penyedia cloud melakukan maintenance pada server fisik (host), virtual machine dipindahkan ke host lain (live migration) atau dihentikan sementara. Selama itu seluruh server terhenti, dan jika jedanya lama, koneksi terputus.
Mengapa: Penyedia memindahkan virtual machine ke host lain atau menjedanya sementara karena maintenance host atau prediksi kerusakan → Akibatnya: Selama dipindahkan, CPU, memori, dan jaringan melambat, dan di akhir proses virtual machine berhenti total sesaat (kurang dari 1 detik hingga sekitar 30 detik, tergantung penyedia dan caranya) → Di layar: Semua pemain di server mengalami freeze bersamaan lalu fast forward atau teleport; jika jedanya lebih lama dari timeout, terjadi disconnect massal
Gejala: Freeze, Fast forward, Teleport, Disconnect · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal)
Selama kartu berhenti dan dimulai ulang karena bug driver atau fitur yang tidak berfungsi dengan benar, semua pengiriman dan penerimaan terputus.
Mengapa: Bug driver, fitur offload tidak berfungsi dengan benar → Akibatnya: NIC berhenti lalu dimulai ulang (beberapa detik) → Di layar: Semua pemain di server itu mengalami freeze bersamaan lalu teleport atau disconnect
Gejala: Freeze, Disconnect · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Fitur ini menggabungkan beberapa paket menjadi satu untuk mengurangi beban CPU. Tergantung konfigurasinya, paket game yang kecil kadang menunggu sebentar paket berikutnya untuk digabung bersama.
Mengapa: NIC atau kernel menggabungkan paket yang datang lalu memprosesnya sekaligus → Akibatnya: Jika penggabungan di hardware (LRO) atau pengaturan waktu tunggu penggabungan aktif, paket menunggu sebentar paket berikutnya → Di layar: Latensi bertambah sedikit (umumnya puluhan µs atau kurang)
Gejala: Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Kernel Linux atau Windows di server menerima koneksi, mengelola buffer socket, serta membagi CPU dan memori ke program server game. Sebagian besar nilai default dibuat konservatif agar cocok untuk berbagai keperluan, sehingga sering tidak pas untuk server game yang melayani puluhan ribu pemain yang terhubung dalam waktu lama.
Saat koneksi baru masuk, kernel menaruh permintaan koneksi di antrean koneksi (backlog), lalu server game mengambilnya satu per satu. Jika antrean penuh, Linux membuang permintaan baru diam-diam, sedangkan Windows mengirim balik respons penolakan. Di Linux, setiap koneksi butuh satu file descriptor (fd), yaitu nomor yang diberikan ke setiap file atau koneksi yang terbuka, dan jumlah fd yang boleh dimiliki satu proses juga ada batasnya. Jika puluhan ribu pemain menekan tombol masuk bersamaan tepat setelah maintenance, antrean koneksi dan fd-lah yang paling dulu habis.
Kernel juga memindahkan memori ke disk saat memori kurang (swap, jika diaktifkan). Jika memori benar-benar habis, Linux memilih proses yang paling banyak memakai memori lalu mematikannya secara paksa (OOM killer). Server game biasanya proses yang paling banyak memakai memori di server itu, sehingga menjadi sasaran pertama. Jika container diberi batas memori, hal yang sama terjadi begitu batas itu tercapai, meskipun server secara keseluruhan masih punya ruang. Hal-hal yang tampak tidak berkaitan dengan game, seperti sinkronisasi waktu (NTP), tugas terjadwal, batas CPU container, dan CPU steal pada virtual machine (waktu menunggu selama VM lain memakai CPU fisik), juga bisa menghentikan server sesaat atau membuat timer meleset.
OS server adalah gerbang masuk dan kantor pengelola taman hiburan. Jika semua orang datang bersamaan pada jam buka (maintenance selesai), antrean di depan gerbang (backlog) meluap, dan jika gelang tiket yang dibagikan (file descriptor) habis, tidak ada lagi yang bisa masuk.
Jika puluhan ribu pemain login bersamaan tepat setelah maintenance, antrean koneksi (backlog) di kernel meluap dan upaya koneksi dibuang.
Mengapa: Begitu maintenance selesai, koneksi berdatangan lebih cepat daripada kecepatan server game memprosesnya dengan accept → Akibatnya: Antrean koneksi kernel (backlog, yaitu nilai yang lebih kecil antara nilai yang diberikan kode server ke listen dan batas atas kernel) penuh → Di layar: Upaya koneksi dibuang dan percobaan ulang terus berulang, sehingga pemain tidak bisa masuk atau mengalami loading tanpa henti
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Setiap koneksi membutuhkan satu file descriptor (fd, nomor yang diberikan OS untuk file dan socket yang terbuka), dan jumlah fd yang bisa dibuka oleh satu proses dibatasi.
Mengapa: Jumlah pemain online bersamaan mencapai batas file descriptor proses → Akibatnya: Server tidak bisa menerima koneksi baru (Too many open files). Membuka file log dan koneksi DB juga ikut gagal → Di layar: Begitu jumlah pemain mencapai angka tertentu, tidak ada lagi yang bisa masuk: pemain baru gagal masuk atau terjebak loading tanpa henti
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika buffer kirim dan buffer terima kecil, saat burst trafik datang paket yang diterima lewat UDP dibuang, dan pengiriman TCP tertahan karena buffer tidak punya ruang.
Mengapa: SO_SNDBUF dan SO_RCVBUF masih default atau terlalu kecil → Akibatnya: Saat burst atau saat thread penerima tertahan sebentar, buffer terima UDP meluap dan paket dibuang; TCP menunggu karena buffer kirim tidak punya ruang → Di layar: Teleport (packet loss UDP) atau fast forward (TCP menunggu)
Gejala: Teleport, Fast forward · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika jumlah thread jauh melebihi jumlah core, OS menghabiskan CPU hanya untuk menjalankan thread-thread itu secara bergiliran.
Mengapa: Ada ratusan hingga ribuan thread, misalnya karena setiap koneksi dibuatkan thread sendiri → Akibatnya: Biaya context switching (pergantian thread yang berjalan) dan cache miss meningkat → Di layar: CPU sibuk tetapi throughput rendah dan tick tidak beraturan, sehingga terjadi patah-patah atau slow motion
Gejala: Patah-patah, Slow motion · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Server game berhenti selama server fisik (hypervisor) sementara memberikan waktu CPU milik virtual machine ini ke virtual machine lain (CPU steal).
Mengapa: Virtual machine lain di host yang sama memakai banyak CPU → Akibatnya: Virtual machine server game kehilangan jatah eksekusi selama beberapa hingga puluhan ms setiap kali → Di layar: Waktu tick melonjak tanpa sebab yang jelas, sehingga terjadi patah-patah atau freeze
Gejala: Patah-patah, Freeze · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pihak Eksternal (Pihak Eksternal)
Jika container diberi batas CPU, begitu kuota dalam satu periode (biasanya 100 ms) habis, container dipaksa berhenti selama sisa periode itu (throttling).
Mengapa: Batas CPU (limit) dipasang pada container server game, misalnya di Kubernetes → Akibatnya: Saat perhitungan tick menumpuk, kuota habis dan proses berhenti puluhan ms sampai periode berikutnya → Di layar: Rata-rata CPU rendah tetapi tick melonjak secara berkala, sehingga terjadi patah-patah atau slow motion
Gejala: Patah-patah, Slow motion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Core CPU yang sedang menganggur masuk ke mode hemat daya yang dalam (C-state) dan menurunkan frekuensinya untuk menghemat listrik. Saat paket atau timer datang, core butuh waktu untuk bangun dan menaikkan frekuensi, sehingga pemrosesan paket kecil mendapat tambahan latensi.
Mengapa: Kebijakan pengaturan frekuensi OS (governor) atau pengaturan daya BIOS mengizinkan C-state yang dalam dan frekuensi rendah → Akibatnya: Setiap kali core yang menganggur bangun dari mode hemat daya yang dalam, ada keterlambatan hingga ratusan µs; jika frekuensi tertahan rendah, perhitungan tick itu sendiri menjadi lambat → Di layar: Biasanya sulit dirasakan, tetapi jika pemanggilan antarserver banyak, keterlambatan menumpuk dan muncul input lag yang justru terjadi saat server sepi. Jika frekuensi tertahan rendah, tick tertinggal saat pemain ramai dan terjadi slow motion
Gejala: Input lag, Slow motion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Saat memori habis, Linux memilih proses yang memakai memori paling banyak lalu mematikannya secara paksa. Biasanya proses itu adalah server game.
Mengapa: Memori habis karena kebocoran atau lonjakan pemakaian, atau batas memori container tercapai → Akibatnya: Kernel menghentikan paksa proses server game → Di layar: Semua pemain di server itu disconnect bersamaan, dan progres terakhir bisa hilang karena rollback
Gejala: Disconnect, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Proses berhenti selama OS memadatkan memori (compaction) untuk membuat halaman besar (huge page) atau mengambil kembali memori (reclaim) agar tersedia ruang kosong.
Mengapa: Memori kosong menipis, atau fitur halaman besar (THP) menjalankan compaction memori → Akibatnya: Thread yang meminta memori menunggu sampai reclaim dan compaction selesai → Di layar: Server berhenti secara tidak teratur (beberapa ms hingga ratusan ms)
Gejala: Freeze, Patah-patah · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika jam server disesuaikan beberapa detik maju atau mundur sekaligus, timer yang bergantung pada jam sistem terpicu bersamaan atau berhenti.
Mengapa: Sinkronisasi waktu menggeser jam dalam jumlah besar sekaligus → Akibatnya: Timer terpicu bertumpuk atau berhenti, dan timeout dinilai keliru → Di layar: Buff dan cooldown kacau, disconnect serentak, fast forward
Gejala: Fast forward, Disconnect, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Kompresi log, backup, dan pemindaian keamanan yang berjalan pada jam yang sama setiap hari menyita CPU dan disk.
Mengapa: Tugas OS dijalankan pada waktu yang sudah ditentukan → Akibatnya: Server game harus berbagi CPU dan disk dengan tugas tersebut → Di layar: Patah-patah atau slow motion pada waktu tertentu, misalnya setiap pukul 04.00 dini hari
Gejala: Patah-patah, Slow motion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Kode game tidak berubah, tetapi server menjadi lambat sejak OS, kernel, driver, atau firmware server diperbarui. Update bisa mengubah nilai default, scheduler, mitigasi kerentanan CPU (mitigations), dan perilaku driver.
Mengapa: Kernel, driver, atau firmware berubah karena patch keamanan rutin atau image server baru → Akibatnya: Nilai default atau scheduler berubah, atau mitigasi kerentanan baru aktif, sehingga pekerjaan yang sama butuh waktu CPU lebih banyak dan urutan thread mendapat jatah CPU berubah → Di layar: Server yang tadinya lancar selalu sedikit lebih lambat sejak hari update, sehingga terjadi input lag, dan saat pemain ramai terjadi patah-patah atau slow motion
Gejala: Input lag, Patah-patah, Slow motion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Jika tabel connection tracking (conntrack), tempat firewall Linux mencatat semua koneksi, mencapai batasnya, paket baru dibuang.
Mengapa: Catatan koneksi bertambah karena lonjakan koneksi atau koneksi pendek yang berulang → Akibatnya: Tabel penuh sehingga koneksi baru dan sebagian paket dibuang → Di layar: Tidak bisa masuk, teleport akibat packet loss tanpa sebab yang jelas
Gejala: Tidak bisa masuk / loading tanpa henti, Teleport · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game)
Jika server game sering membuka dan menutup koneksi singkat ke DB atau server lain, koneksi yang sudah ditutup tetap menahan port untuk sementara sehingga koneksi baru tidak bisa dibuka.
Mengapa: Koneksi baru dibuka dan ditutup untuk setiap permintaan → Akibatnya: Pihak yang menutup koneksi lebih dulu menahan port selama sekitar 60 detik (Linux) dalam status TIME_WAIT, sehingga port yang bisa dipakai habis → Di layar: Permintaan internal gagal, sehingga penyimpanan data gagal dan fitur mengalami error
Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Bagian ini menentukan cara game mengirim dan menerima data lewat jaringan. Pada koneksi yang sama, kehilangan satu paket bisa berakhir sebagai “sedikit tersendat”, tetapi bisa juga menjadi “berhenti 1 detik lalu fast forward”, tergantung protokol yang dipakai dan cara opsi socket diaktifkan.
TCP menjamin data sampai lengkap sesuai urutan pengiriman. Konsekuensinya, jika satu paket hilang, TCP menahan semua data, termasuk yang tiba sesudahnya, dan tidak meneruskannya ke game sampai paket itu diterima ulang. UDP tidak menjamin apa pun. Data yang tiba langsung diteruskan tanpa menunggu, tetapi data yang hilang harus ditangani sendiri oleh game. Karena itu, game dengan aksi intens membangun sendiri keandalan secukupnya di atas UDP (reliable UDP), sedangkan banyak MMO memakai TCP yang lebih mudah diimplementasikan dan menerima kelemahannya.
Opsi socket adalah pengaturan detail perilaku ini: apakah paket kecil dikumpulkan dulu sebelum dikirim (TCP_NODELAY), seberapa besar buffer kirim dan terima (SO_SNDBUF, SO_RCVBUF), kapan koneksi yang mati terdeteksi (SO_KEEPALIVE, TCP_USER_TIMEOUT), dan apa yang dilakukan pada data tersisa saat koneksi ditutup (SO_LINGER). Sebagian besar nilai default disetel untuk mengirim data besar secara efisien dengan sedikit paket, sehingga sering merugikan game yang sering bertukar paket kecil.
TCP meneruskan data yang diterima ke game hanya sesuai urutan pengiriman. Jika paket ke-17 hilang, paket ke-18 sampai ke-30 tetap menunggu sampai paket ke-17 datang lagi meskipun sudah tiba (HOL blocking). UDP meneruskan data begitu tiba, sehingga sisanya tetap diproses tepat waktu meskipun paket ke-17 tidak pernah datang.
Mengapa retransmisi terjadi (Wi-Fi, kongesti, MTU black hole, retransmisi yang tidak perlu, dan lainnya) serta cara mencari penyebabnya dibahas per penyebab di 06 Retransmisi TCP.
Untuk menjaga urutan, TCP tidak menyerahkan paket yang datang belakangan ke game sampai satu paket yang hilang diterima ulang.
Mengapa: Satu paket hilang → Akibatnya: Paket-paket sesudahnya sudah tiba, tetapi menunggu di buffer terima → Di layar: Berhenti, lalu semuanya dilepas sekaligus sehingga terjadi fast forward
Gejala: Freeze, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Setiap kali retransmisi gagal lagi, waktu tunggu berlipat dua, sehingga koneksi yang putus sebentar berujung pada jeda yang lama.
Mengapa: Koneksi putus sebentar sehingga retransmisi pun gagal berturut-turut → Akibatnya: Waktu tunggu sampai percobaan berikutnya berlipat dua: 0,3 → 0,6 → 1,2 → 2,4 detik (untuk ping 100 ms) → Di layar: Koneksi hanya putus 1 detik, tetapi game freeze lebih dari 2 detik. Jika putusnya lebih lama, akhirnya disconnect
Gejala: Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Algoritma Nagle yang mengumpulkan paket kecil sebelum dikirim dan delayed ACK yang menunda pengiriman ACK saling mengunci, sehingga setiap kali pesan ditulis terpisah-pisah terjadi keterlambatan 40–200 ms.
Mengapa: Pesan kecil ditulis terpisah-pisah tanpa mengaktifkan TCP_NODELAY → Akibatnya: Pengirim menunggu ACK, sedangkan penerima menunda pengiriman ACK → Di layar: Ping koneksi rendah, tetapi semua aksi terasa lamban secara konsisten (input lag)
Gejala: Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika buffer kirim untuk satu pemain dengan koneksi lambat sudah penuh, lalu server mengirim dengan cara blocking (pemanggilan yang tidak kembali sampai buffer punya ruang), thread server ikut menunggu pemain itu.
Mengapa: Buffer kirim untuk klien yang lambat penuh → Akibatnya: Karena pengirimannya blocking, thread server menunggu sampai buffer punya ruang → Di layar: Semua pemain yang ditangani thread itu mengalami freeze atau slow motion
Gejala: Freeze, Slow motion · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Untuk klien yang data kirimannya terus menumpuk, server membuang update lama atau memutus koneksinya.
Mengapa: Koneksi klien tidak sanggup mengimbangi jumlah data yang dikirim server → Akibatnya: Server membuang update lama atau memutus koneksi saat batas terlampaui → Di layar: Hanya pemain itu yang mengalami teleport atau disconnect
Gejala: Teleport, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika pihak lawan menghilang tanpa sinyal penutupan, TCP baru mendeteksinya lama kemudian. keepalive (fitur TCP untuk memeriksa apakah koneksi idle masih hidup) nonaktif secara default, dan walaupun diaktifkan, pemeriksaan baru dimulai setelah koneksi idle selama 2 jam.
Mengapa: Klien menghilang tanpa sinyal penutupan karena perangkat mati atau koneksi putus → Akibatnya: Server menganggap koneksi masih hidup (keepalive default 7.200 detik; jika ada data yang sedang dikirim, sekitar 15 menit sampai retransmisi menyerah) → Di layar: Karakter hantu tertinggal, dan saat login ulang muncul error “Sudah terhubung”
Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Paket UDP yang melebihi MTU (ukuran maksimum yang bisa dikirim sekaligus) difragmentasi di lapisan IP, dan jika satu fragmen saja hilang, seluruh paket dibuang.
Mengapa: Snapshot di tempat ramai melebihi 1.500 byte → Akibatnya: Paket dikirim terpecah menjadi beberapa fragmen; jika satu saja hilang, seluruhnya dibuang → Di layar: Makin besar paketnya, tingkat packet loss naik beberapa kali lipat. Teleport hanya terjadi di tempat ramai
Gejala: Teleport · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika aturan retransmisi yang dibuat sendiri di atas UDP terlalu konservatif, pemulihan terlambat; jika terlalu agresif, jalur makin padat.
Mengapa: Pengaturan interval retransmisi, jumlah percobaan, dan ukuran window tidak sesuai dengan koneksi → Akibatnya: Pemulihan terlambat, atau pengiriman duplikat memperparah kongesti → Di layar: Skill tidak keluar, fast forward, lag yang makin parah saat jalur padat
Gejala: Aksi hilang / rollback, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika koneksi idle cukup lama, TCP kembali mengecilkan congestion window (jumlah data yang bisa dikirim sekaligus), sehingga data besar yang tiba-tiba dikirim harus dipecah menjadi beberapa kali kirim.
Mengapa: Data besar, misalnya saat masuk ke kota, dikirim lewat koneksi yang tadinya idle → Akibatnya: Congestion window sedang kecil sehingga data dikirim terbagi dalam beberapa kali pulang-pergi → Di layar: Tepat setelah masuk, karakter dan NPC di sekitar muncul terlambat beberapa kali waktu pulang-pergi (makin jauh servernya, makin terasa)
Gejala: Input lag, Tidak terlihat / objek hantu · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
TCP menganggap packet loss sebagai tanda kongesti dan menurunkan kecepatan kirim 30–50%. TCP bereaksi sama terhadap packet loss di Wi-Fi.
Mengapa: Saat data yang dikirim banyak, terjadi sedikit packet loss di Wi-Fi atau di jalur koneksi → Akibatnya: TCP menurunkan kecepatan kirim secara drastis lalu pulih perlahan (CUBIC, default di Linux dan Windows, menurunkannya 30%) → Di layar: Di tempat ramai, update tertunda sehingga terjadi fast forward atau input lag
Gejala: Fast forward, Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika server memutus koneksi secara mendadak, pesan pemberitahuan atau sinyal penyimpanan selesai yang dikirim terakhir ikut hilang.
Mengapa: Server menutup koneksi dengan penutupan paksa (RST). Terjadi jika SO_LINGER diatur ke 0 detik, atau socket ditutup sebelum semua data yang diterima dibaca → Akibatnya: Alasan kick dan data terakhir yang masih dalam pengiriman dibuang → Di layar: Muncul pesan “Koneksi terputus karena error yang tidak diketahui” tanpa alasan yang jelas
Gejala: Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Pada arsitektur yang membuat thread tidak bisa mengerjakan hal lain selama menunggu satu socket, seluruh server makin lambat seiring bertambahnya pemain.
Mengapa: Cara kerja yang menunggu baca dan tulis untuk setiap koneksi → Akibatnya: Keterlambatan satu koneksi merembet ke koneksi lain di thread yang sama → Di layar: Makin banyak pemain online, seluruh server makin terasa slow motion dan input lag
Gejala: Slow motion, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika beberapa proses berbagi satu port, kernel menetapkan proses yang menangani setiap koneksi berdasarkan hash alamat dan tidak mengubahnya. Jika satu proses itu berhenti, hanya pemain yang dialokasikan ke proses tersebut yang menunggu.
Mengapa: Gateway atau server login menjalankan beberapa proses dengan SO_REUSEPORT → Akibatnya: Walaupun satu proses berhenti karena GC atau kelebihan beban, koneksi baru dan paket UDP yang dialokasikan ke proses itu tidak dialihkan ke proses lain → Di layar: Hanya sebagian pemain yang tidak bisa masuk atau freeze. Saat restart yang mengubah jumlah proses, sebagian sesi UDP terputus
Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika server Windows mengirim UDP ke klien yang sudah pergi, notifikasi “port tidak ada” (ICMP) dikirim balik. Notifikasi itu membuat pemanggilan terima berikutnya berakhir dengan error. Jika kode server memperlakukan error ini sebagai kerusakan socket itu sendiri, semua pemain yang memakai socket tersebut ikut terdampak.
Mengapa: UDP terus dikirim ke alamat klien yang baru saja keluar, sehingga notifikasi “port tidak ada” (ICMP) dikirim balik → Akibatnya: Windows mengakhiri pemanggilan terima berikutnya dengan error WSAECONNRESET (10054), lalu kode server berhenti menerima atau menutup socket → Di layar: Semua pemain yang memakai socket itu freeze atau disconnect bersamaan
Gejala: Disconnect, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Inilah program yang benar-benar menghitung logika game. Gerakan, pertarungan, AI monster, perhitungan jarak pandang, dan broadcast semuanya harus selesai dalam satu “tick”. Makin banyak pemain berkumpul di satu tempat, perhitungan jarak pandang dan paket yang harus dikirim bertambah sebanding dengan kuadrat jumlah pemain.
Server menghitung state game pada interval tick yang tetap. Pada server 20 tick, sekali setiap 50 ms server menerapkan input semua pemain, menggerakkan monster, menghitung siapa bisa melihat siapa (jarak pandang, AOI), lalu mengirim perubahan ke semua pemain yang bisa melihatnya. Waktu 50 ms inilah yang disebut tick budget (batas waktu per tick). Jika budget terlampaui, tick berikutnya terlambat. Pada server yang memajukan waktu game dengan jumlah tetap per tick, seluruh waktu di dunia game mengalir lebih lambat (slow motion). Server yang memajukan waktu sebanyak waktu nyata yang berlalu tetap menjaga kecepatan game, tetapi paketnya menjadi jarang sehingga terjadi patah-patah dan teleport. Pada kedua cara, respons menjadi lambat. Jika satu thread game menangani seluruh server (channel), semua pemain di server itu mengalaminya; jika thread dibagi per wilayah, pemain di wilayah itulah yang mengalaminya bersama.
Masalahnya ada pada jumlah pemain. Jika setiap pemain dibandingkan dengan semua pemain lain, 100 orang berarti sekitar 10.000 perbandingan dan 1.000 orang sekitar 1 juta perbandingan di setiap tick. Karena itu, server membagi peta menjadi grid dan hanya membandingkan sel yang berdekatan. Namun, jika semua orang berkumpul di sekitar satu sel, seperti saat world boss, siege, atau event di alun-alun kota, efek grid berkurang dan jumlah perhitungan serta data yang harus dikirim meledak. Jika ditambah lock (beberapa thread menunggu data yang sama) dan pemanggilan sinkron (menunggu respons DB di tengah tick), semua pemain yang ditangani thread itu ikut terhenti selama thread menunggu.
Tick server adalah ketukan birama dirigen. Makin banyak anggota orkestra (pemain), makin banyak partitur yang harus diurus dalam satu ketukan, dan jika ketukan terlewat, seluruh lagu melambat. Jika ada yang pergi ke gudang (DB) untuk mencari selembar partitur, semua orang menunggunya.
Jika pekerjaan dalam satu tick melewati tick budget (batas waktu per tick), interval tick server memanjang, dan seluruh area itu berjalan lambat atau patah-patah.
Mengapa: Pekerjaan yang harus diproses dalam satu tick (misalnya 50 ms) melewati budget → Akibatnya: State game yang seharusnya dihitung 20 kali per detik hanya dihitung 8 kali → Di layar: Seluruh area itu slow motion (atau patah-patah, tergantung desain server), respons skill terlambat
Gejala: Slow motion, Input lag, Patah-patah · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika siapa bisa melihat siapa dihitung dengan membandingkan semua pemain satu sama lain, saat jumlah pemain naik 10 kali, perhitungannya naik 100 kali.
Mengapa: Jarak dibandingkan antara semua karakter, atau walaupun sudah dibagi dengan grid, ratusan pemain berkumpul di dekat satu sel → Akibatnya: 100 pemain berarti sekitar 10.000 perbandingan, 1.000 pemain sekitar 1 juta perbandingan → Di layar: Di tempat ramai seperti world boss atau siege, waktu tick melonjak sehingga terjadi slow motion atau patah-patah
Gejala: Slow motion, Patah-patah · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika gerakan satu pemain dikirim ke semua yang melihatnya, jumlah update yang harus dikirim menjadi kuadrat dari jumlah pemain yang berkumpul.
Mengapa: Perubahan satu pemain dikirim ke semua yang bisa melihatnya → Akibatnya: Jika 1.000 pemain saling melihat, ada 1 juta update setiap tick → Di layar: Antrean kirim dan bandwidth jenuh sehingga terjadi keterlambatan dan packet loss (input lag, fast forward, teleport)
Gejala: Input lag, Teleport, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Pada arsitektur yang menugaskan satu thread untuk setiap area, jika pemain berkumpul di satu tempat, hanya satu core itu yang mencapai 100%.
Mengapa: Satu area (channel) ditangani oleh satu thread → Akibatnya: Jika pemain berkumpul di satu tempat, hanya core itu yang jenuh, sedangkan core lain masih longgar → Di layar: Hanya area itu yang lag, area lain normal
Gejala: Slow motion, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika beberapa thread menunggu satu lock untuk menulis data yang sama, walaupun thread ditambah, hanya satu yang berjalan pada satu waktu.
Mengapa: Beberapa thread memakai data bersama secara bersamaan, misalnya balai lelang atau gudang guild → Akibatnya: Thread lain menunggu sampai thread yang memegang lock selesai → Di layar: Hanya fitur tertentu yang lambat; jika parah, tick seluruh server tertunda
Gejala: Input lag, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika dua thread saling menunggu lock yang dipegang thread lainnya, keduanya berhenti selamanya.
Mengapa: Thread A memegang lock 1 dan menunggu lock 2, sedangkan thread B memegang lock 2 dan menunggu lock 1 → Akibatnya: Keduanya berhenti selamanya, dan thread lain yang terkait ikut berhenti satu per satu → Di layar: Seluruh server berhenti, lalu watchdog memulai ulang server sehingga semua pemain disconnect
Gejala: Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika di tengah tick server menunggu respons DB atau penulisan file, seluruh jalannya game di server berhenti selama waktu itu.
Mengapa: Di dalam tick, server menunggu query dan penyimpanan DB, penulisan log, atau pemanggilan API eksternal → Akibatnya: Jika DB butuh 100 ms, tick juga berhenti 100 ms → Di layar: Setiap kali DB atau disk melambat, seluruh field tersendat sesaat
Gejala: Freeze, Patah-patah · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika permintaan masuk lebih cepat daripada kecepatan pemrosesan dan menumpuk di antrean, permintaan di belakang baru diproses beberapa detik kemudian atau dibuang.
Mengapa: Permintaan datang lebih cepat daripada kecepatan pemrosesan → Akibatnya: Antrean memanjang, dan permintaan dibuang begitu melewati batas → Di layar: Respons skill dan trade terlambat, atau aksinya hilang
Gejala: Input lag, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika respawn semua monster, berakhirnya semua buff, dan hadiah tepat di pergantian jam menumpuk di tick yang sama, tick itu saja menjadi puluhan kali lebih berat.
Mengapa: Timer respawn, kedaluwarsa, hadiah, dan simpan otomatis diatur ke waktu yang sama → Akibatnya: Dalam satu tick itu, pekerjaannya puluhan kali lipat dari biasanya → Di layar: Tersendat sesaat setiap kali waktu yang ditentukan tiba
Gejala: Freeze, Patah-patah · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika ratusan monster mengejar pemain secara bersamaan sambil menghitung rute, pemakaian CPU menjadi sangat besar.
Mengapa: Monster mengejar secara bersamaan saat mob pulling (menarik banyak monster sekaligus) atau spawn besar-besaran → Akibatnya: Pathfinding dihitung untuk setiap monster → Di layar: Hanya area berburu itu yang slow motion
Gejala: Slow motion · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Mengubah data yang akan dikirim menjadi byte dan mengompresinya juga memakan CPU, dan biaya ini melonjak saat pemain banyak.
Mengapa: Setiap update, struct diubah menjadi byte lalu dikompresi → Akibatnya: Biaya naik sebanding dengan kuadrat jumlah pemain → Di layar: Pengiriman terlambat sehingga terjadi input lag
Gejala: Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika proses server mati karena error yang tidak tertangani, semua pemain di server itu disconnect bersamaan.
Mengapa: Error fatal seperti error yang menunjuk objek yang tidak ada (null reference), data yang salah, atau memori habis → Akibatnya: Proses server (atau zona) mati → Di layar: Semua pemain disconnect bersamaan, dan progres bisa kembali ke kondisi saat penyimpanan terakhir (rollback)
Gejala: Disconnect, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika semua worker thread tertahan oleh pekerjaan lambat, permintaan baru hanya bisa menunggu tanpa kepastian.
Mengapa: Worker thread tertahan karena menunggu respons API eksternal atau DB → Akibatnya: Tidak ada thread yang bisa ditugaskan untuk permintaan baru → Di layar: Fitur tertentu seperti login atau toko mengalami loading tanpa henti
Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika satu tick tidak pernah selesai karena bug, server berhenti, lalu watchdog memulai ulang server secara paksa.
Mengapa: Perulangan tidak pernah selesai karena kondisi yang salah, atau rekursi lepas kendali → Akibatnya: Tick tidak selesai sehingga server berhenti → Di layar: Game freeze, lalu semua pemain disconnect
Gejala: Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika ratusan pemain menyerang satu boss secara bersamaan, perhitungan untuk boss itu terpusat di satu tempat, dan informasi setiap serangan dikirim ke semua yang melihatnya.
Mengapa: Ratusan pemain terus-menerus memakai skill, buff, dan debuff pada satu boss → Akibatnya: Perhitungan HP, daftar aggro, dan debuff boss terpusat di satu tempat, dan setiap serangan mengirim paket angka damage dan efek ke semua yang melihat → Di layar: Skill terlambat masuk dan angka damage muncul sekaligus, hanya area sekitar boss yang slow motion
Gejala: Input lag, Fast forward, Slow motion · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Saat pemain memakai teleportasi ke kota yang ramai, server harus mengirim tampilan, perlengkapan, dan status ratusan pemain yang baru terlihat sekaligus.
Mengapa: Pemain tiba-tiba muncul di tempat ramai karena teleportasi, login, atau pindah channel → Akibatnya: Server membuat dan mengirim informasi lengkap ratusan pemain sekaligus, dan PC Anda juga memuat semuanya sekaligus → Di layar: Layar freeze sebentar tepat setelah tiba, karakter muncul satu per satu dengan terlambat, dan terjadi input lag
Gejala: Freeze, Input lag, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game)
Jika item di tanah, summon, dan timer yang sudah selesai tidak dibersihkan dan terus menumpuk, makin lama server menyala, makin banyak pekerjaan di setiap tick.
Mengapa: Item di tanah, summon, timer kedaluwarsa, dan data party kosong tidak dihapus tepat waktu → Akibatnya: Daftar yang ditelusuri setiap tick makin panjang setiap hari → Di layar: Normal tepat setelah maintenance, tetapi setelah beberapa hari hanya server atau area itu yang makin lamban
Gejala: Slow motion, Patah-patah, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika konten, efek, dan data sinkronisasi baru memperbesar ukuran dan frekuensi paket, server yang tadinya lancar mulai terbentur batas MTU, bandwidth, dan jumlah paket setelah patch.
Mengapa: Patch menambah efek skill, data sinkronisasi, dan informasi item baru sehingga paket menjadi lebih besar atau lebih sering → Akibatnya: Paket besar melewati MTU sehingga terfragmentasi, dan volume yang bertambah terbentur bandwidth, batas PPS cloud, dan buffer kirim → Di layar: Sejak tepat setelah patch, terjadi teleport, skill tidak keluar, dan input lag di tempat ramai. Infrastruktur tidak diubah sama sekali, tetapi packet loss bertambah
Gejala: Teleport, Aksi hilang / rollback, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur)
Semua yang diingat server, yaitu karakter, monster, item, dan peta, berada di memori. Memori itu sendiri cepat, tetapi lag terjadi saat server berhenti karena GC (pengambilan kembali memori yang tidak dipakai), saat memori bocor sedikit demi sedikit (kebocoran), atau saat memori kurang sehingga terjadi swap (sebagian memori dipindahkan ke disk).
Bahasa yang mengelola memori secara otomatis, seperti Java, C#, dan Go, memakai garbage collector (GC) untuk mengumpulkan dan mengambil kembali memori yang sudah dipakai lalu dibuang. Tergantung jenis GC-nya, semua thread bisa dihentikan sejenak. Jika GC dijalankan pada seluruh heap (area memori yang dialokasikan dan dipakai program saat berjalan) sekaligus, prosesnya makin lama jika data hidup makin banyak, hingga ratusan ms sampai beberapa detik. GC modern seperti ZGC memperpendek jeda hingga kurang dari 1 ms, dengan imbalan memakai lebih banyak CPU dan memori. Server C++ tidak punya GC, tetapi rawan kebocoran (memori yang lupa dibebaskan terus menumpuk) dan fragmentasi (ruang kosong terpecah kecil-kecil sehingga blok besar tidak bisa dipakai). Meskipun ada GC, kebocoran tetap terjadi jika objek yang sudah selesai dipakai masih terus direferensikan di suatu tempat.
Alasan lain memori bisa lambat adalah hierarki memori (seberapa jauh media penyimpanan dari CPU). Cache tepat di samping CPU butuh 1 ns, RAM 100 ns, dan membaca kembali memori yang dipindahkan ke disk (swap) butuh lebih dari 1.000 kali waktu RAM. Di tabel “Skala angka” di bawah, coba perbesar selisih ini ke skala waktu manusia.
Memori adalah meja kerja koki. Jika bahan ada dalam jangkauan tangan (cache), pekerjaan cepat. Jika harus ke kulkas (RAM), sedikit lebih lambat. Jika meja kerja penuh sehingga bahan disimpan di gudang (disk, swap), setiap kali mengambilnya butuh waktu lama. Selama mencuci piring (GC), memasak harus berhenti.
Selama server Java atau C# menghentikan semua thread untuk mengumpulkan garbage (stop-the-world), seluruh server berhenti.
Mengapa: Heap penuh, GC dimulai → Akibatnya: Semua thread game dihentikan untuk pengumpulan garbage (makin banyak data hidup, makin lama) → Di layar: Semua pemain di server berhenti bersamaan, lalu fast forward
Gejala: Freeze, Fast forward · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Walaupun servernya ditulis dengan C++, jika quest, AI, dan skill dijalankan dengan skrip seperti Lua, zona itu berhenti selama GC engine skrip berjalan.
Mengapa: Engine skrip di setiap zona menjalankan quest, AI, dan event sambil membuat objek sementara dalam jumlah besar → Akibatnya: Saat GC engine skrip mengumpulkan banyak garbage sekaligus, tick zona itu terhenti → Di layar: Tersendat sesaat secara berkala, hanya di zona tertentu atau selama event tertentu
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika objek sementara dibuat dalam jumlah besar selama event, GC berjalan jauh lebih sering daripada biasanya.
Mengapa: Objek sementara melonjak karena drop item, log pertempuran, dan hadiah event → Akibatnya: GC berjalan beberapa kali lebih sering, dan objek yang belum sempat dibuang pindah ke old generation sehingga Full GC juga datang lebih cepat → Di layar: Tersendat sesaat secara berkala, hanya saat event
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Memori yang tidak dibebaskan menumpuk sedikit demi sedikit, lalu beberapa hari kemudian berujung pada GC yang berjalan tanpa henti, swap, atau proses yang dihentikan paksa.
Mengapa: Data karakter yang sudah logout dan event handler tidak dibebaskan → Akibatnya: Memori bebas berkurang selama beberapa hari → Di layar: Normal tepat setelah maintenance, makin hari makin lag, akhirnya server down
Gejala: Slow motion, Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika data hidup mendekati batas heap, GC hampir tidak bisa membebaskan memori setiap kali berjalan, sehingga GC berulang tanpa henti.
Mengapa: Data hidup memenuhi heap hingga mendekati batasnya karena jumlah pemain bertambah saat event atau karena kebocoran → Akibatnya: GC hanya membebaskan sedikit memori sehingga Full GC langsung berjalan lagi, dan sebagian besar CPU terpakai untuk GC → Di layar: Seluruh server berulang kali slow motion dan freeze selama beberapa menit, lalu mati karena kehabisan memori
Gejala: Slow motion, Freeze, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika memori kurang dan OS memindahkan sebagiannya ke disk, setiap kali memori itu dipakai, proses harus menunggu disk yang lebih dari 1.000 kali lebih lambat.
Mengapa: Memori yang dipakai melebihi RAM fisik → Akibatnya: OS memindahkan sebagian memori ke disk dan membacanya lagi saat dibutuhkan → Di layar: Tick melonjak hingga ratusan ms, sehingga semua pemain di server mengalami slow motion dan freeze
Gejala: Slow motion, Freeze · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika data tersebar di berbagai tempat di memori, CPU harus menunggu setiap kali mengambilnya dari RAM yang lambat.
Mengapa: Objek tersebar lewat pointer dan diakses tanpa urutan → Akibatnya: Data tidak ada di cache CPU sehingga setiap kali harus dibaca dari RAM (sekitar 100 kali lebih lambat) → Di layar: Untuk pekerjaan yang sama, biaya tick menjadi beberapa kali lipat; jika parah, terjadi slow motion
Gejala: Slow motion · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Jika alokasi dan pembebasan yang berulang memecah ruang kosong menjadi potongan kecil, proses menahan memori jauh lebih banyak daripada yang benar-benar dipakai.
Mengapa: Banyak thread mengalokasikan dan membebaskan memori berukuran beragam dalam waktu lama → Akibatnya: Ruang kosong tersebar dalam potongan kecil sehingga tidak bisa dikembalikan ke OS, dan penggunaan memori terus naik seperti kebocoran → Di layar: Makin lama menyala, makin lambat karena swap atau kehabisan memori, lalu dihentikan paksa
Gejala: Slow motion, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Pada server dengan dua CPU, akses memori melambat jika thread memakai memori yang terpasang pada CPU seberang.
Mengapa: Thread dan memori ditempatkan di socket CPU yang berbeda → Akibatnya: Akses memori melambat (1,5–2 kali, tergantung perangkat) → Di layar: Spesifikasi sama, tetapi performa berbeda di setiap proses
Gejala: Slow motion · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Log, data karakter yang disimpan, data peta, dan file DB semuanya ada di disk. Disk ratusan kali (SSD) hingga 100.000 kali (HDD) lebih lambat daripada memori, sehingga jika server game dirancang menunggu disk, game ikut berhenti begitu disk sibuk.
Performa disk diukur dengan “berapa kali bisa membaca dan menulis per detik” (IOPS). HDD lama hanya sedikit di atas 150 kali, sedangkan SSD puluhan ribu hingga ratusan ribu kali. Batas disk cloud ditentukan oleh biaya yang dibayar (gp3, tipe default di AWS, 3.000 kali). Sebagian disk cloud dan spesifikasi server kecil memberi burst credit yang memungkinkan performa lebih tinggi untuk sementara di atas kecepatan normal. Jika jam sibuk berlangsung lama, kreditnya habis dan kecepatannya tiba-tiba turun. Laporan seperti “setiap malam, setelah beberapa jam, mulai lag” punya pola ini.
Kuncinya adalah siapa yang menunggu. Penulisan file biasa umumnya langsung selesai karena OS menampungnya dulu di memori lalu menuliskannya ke disk belakangan. Masalah muncul saat program meminta menunggu “sampai data benar-benar ditulis ke disk” (fsync), atau saat batas yang bisa ditampung OS di memori sudah penuh. Jika thread game menunggu sendiri (sinkron), tick ikut berhenti 100 ms saat disk tertunda 100 ms. Jika penulisan diserahkan ke thread terpisah (asinkron), game tidak berhenti, tetapi data yang belum sempat ditulis bisa hilang jika server tiba-tiba crash (aksi hilang / rollback).
Disk adalah gudang, dan IOPS adalah jumlah pintu gudang. Jika pintunya sedikit, orang yang memasukkan dan mengeluarkan barang harus mengantre. Burst credit adalah stamina untuk sprint sebentar; begitu habis, kecepatannya kembali ke kecepatan berjalan.
Jika thread game menunggu disk selesai menulis untuk setiap baris log, jalannya game ikut berhenti saat disk sibuk.
Mengapa: Log pertempuran dan trade langsung ditulis ke file dari thread game → Akibatnya: Jika penyimpanan pasti (fsync) diminta atau buffer tulis OS (page cache) mencapai batasnya, satu kali penulisan butuh puluhan ms saat disk sibuk → Di layar: Tersendat sesaat dalam pertempuran yang menghasilkan banyak log
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Permintaan agar data ditulis ke disk secara “pasti” memakan 0,1 ms hingga puluhan ms per kali tergantung disknya, dan jika permintaan menumpuk, antreannya memanjang.
Mengapa: Permintaan penulisan pasti menumpuk karena penyimpanan berkala dan gelombang logout → Akibatnya: Antrean disk memanjang → Di layar: Lag setiap kali waktu penyimpanan tiba, logout dan pindah channel tertunda
Gejala: Patah-patah, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Infrastruktur DB (Tim Infrastruktur)
Sebagian disk cloud dan spesifikasi server kecil punya burst credit yang memungkinkan kinerja di atas baseline untuk sementara. Jika masa sibuk berlangsung lama dan kreditnya habis, kecepatannya tiba-tiba turun.
Mengapa: Dipakai di atas performa baseline dalam waktu lama → Akibatnya: Burst credit habis, performa anjlok ke baseline → Di layar: Setiap malam, lag baru mulai setelah beberapa jam berlalu
Gejala: Patah-patah, Slow motion, Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika permintaan melebihi jumlah yang bisa diproses disk per detik, antrean memanjang dan latensi melonjak tajam.
Mengapa: Permintaan baca dan tulis mendekati kemampuan proses disk → Akibatnya: Antrean memanjang (biasanya melonjak tajam saat utilisasi 90% atau lebih) → Di layar: Penyimpanan dan loading tertunda; jika pemanggilannya sinkron, terjadi freeze
Gejala: Input lag, Freeze · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game), Infrastruktur DB (Tim Infrastruktur)
Jika log dan dump menumpuk hingga disk penuh, penulisan gagal, dan tanpa penanganan, server crash.
Mengapa: Log, dump, dan file sementara menumpuk hingga 100% → Akibatnya: Penulisan gagal. Tanpa penanganan error, server crash; dengan penanganan error, penyimpanan gagal → Di layar: Disconnect, rollback progres
Gejala: Disconnect, Aksi hilang / rollback · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Jika backup dini hari, kompresi log, dan pemindaian keamanan memonopoli disk, pembacaan dan penulisan server game tertunda.
Mengapa: Tugas backup dan kompresi terjadwal dimulai → Akibatnya: Menghabiskan sebagian besar bandwidth disk dan IOPS → Di layar: Lag di jam yang sama setiap hari
Gejala: Patah-patah, Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika server membaca data dungeon atau map dari disk saat pertama kali diminta, semua pemain berhenti selama tick itu.
Mengapa: Seseorang masuk ke dungeon atau area untuk pertama kali → Akibatnya: Server membaca data dari disk di thread game → Di layar: Semua pemain di server itu mengalami freeze sesaat
Gejala: Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Saat server crash, memori sebesar beberapa GB ditulis ke disk, sehingga restart bisa tertunda beberapa menit.
Mengapa: Server crash, seluruh memori ditulis ke file → Akibatnya: Restart tidak bisa dilakukan selama beberapa GB ditulis → Di layar: Server crash sehingga pemain disconnect, lalu untuk waktu lama tidak bisa masuk
Gejala: Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Pada HDD, head harus bergerak di atas piringan (platter) untuk mencari posisi data (seek), sehingga membaca atau menulis data yang tersebar memakan hampir 10 ms per kali.
Mengapa: Server lama atau storage murah memakai HDD → Akibatnya: Sekitar 10 ms untuk setiap baca atau tulis yang tersebar → Di layar: Penyimpanan dan loading melambat secara umum
Gejala: Input lag · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game)
Di sinilah tersimpan hal-hal yang sama sekali tidak boleh hilang, seperti karakter, item, mata uang game, dan riwayat trade. Saat DB melambat, pertarungan tetap normal, tetapi item terlambat masuk, trade gagal, dan login tidak kunjung selesai. Jika server game dirancang menunggu DB, seluruh field ikut berhenti.
Server game membuka beberapa koneksi ke DB lebih dulu (connection pool) dan memakainya bergantian. Jika satu query (permintaan yang dikirim ke DB) memakan waktu lama, koneksi itu terus terpakai, dan jika semua koneksi di pool sedang terpakai, permintaan lain menunggu di antrean. Ada dua alasan umum query melambat: tidak ada indeks (seperti indeks di buku) sehingga seluruh tabel harus dibaca (full table scan), atau beberapa permintaan mencoba mengubah baris yang sama bersamaan lalu menunggu lock.
Agar andal dan sanggup menerima banyak permintaan, DB memakai beberapa mekanisme: replika yang ikut melayani pembacaan, DB cadangan yang mengambil alih saat terjadi gangguan, dan checkpoint yang secara berkala menulis perubahan ke disk sekaligus. Saat checkpoint menumpuk, DB melambat sesaat. Jika replika tertinggal, muncul keluhan “item yang baru dibeli tidak terlihat”. Jika failover ke DB cadangan terjadi saat replikasi masih tertinggal, muncul gejala aksi hilang atau rollback seperti “setelah login, kondisinya kembali ke beberapa saat lalu”. Jika server game hanya menyimpan karakter sekali setiap beberapa menit, crash server berarti “kembali ke 10 menit yang lalu”.
DB adalah loket bank. Jumlah loket (connection pool) terbatas, dan jika satu permintaan membongkar seluruh buku besar (full table scan), semua permintaan di belakangnya menunggu. Jika semua orang ingin membuka brankas yang sama (hot row), hanya satu orang yang bisa masuk pada satu waktu.
Tanpa indeks, DB harus membaca seluruh tabel untuk menemukan baris yang memenuhi kondisi (full table scan).
Mengapa: Deploy fitur baru menambahkan pencarian dengan kondisi yang tidak punya indeks → Akibatnya: Jutaan baris dipindai semua, sehingga satu query butuh ratusan ms hingga beberapa detik → Di layar: Loading mailbox dan riwayat trade tertunda, koneksi tertahan sehingga request lain ikut menunggu
Gejala: Input lag, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika semua orang ingin mengubah baris yang sama (gudang guild, item populer di balai lelang, counter untuk seluruh server), lock hanya didapat satu per satu.
Mengapa: Perubahan menumpuk pada baris yang sama karena event atau item populer → Akibatnya: Request menunggu sampai mendapat lock → Di layar: Trade gagal, “Coba lagi nanti”, timeout
Gejala: Aksi hilang / rollback, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika dua transaksi (sekumpulan operasi DB yang diproses sebagai satu kesatuan) saling menunggu baris yang dikunci pihak lain, DB membatalkan salah satunya secara paksa.
Mengapa: Trade A mengunci dengan urutan item→mata uang game, trade B dengan urutan mata uang game→item → Akibatnya: DB mendeteksi deadlock dan melakukan rollback pada salah satunya → Di layar: Trade dan crafting sesekali gagal, item kembali seperti semula
Gejala: Aksi hilang / rollback, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jumlah koneksi yang dibuka ke DB terbatas, jadi jika query lambat menahan koneksi, request lainnya harus menunggu.
Mengapa: Semua koneksi terpakai karena query lambat atau lonjakan request → Akibatnya: Request baru menunggu sampai ada koneksi yang kosong → Di layar: Loading tanpa henti saat login, penyimpanan tertunda, timeout
Gejala: Tidak bisa masuk / loading tanpa henti, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Penulisan dilakukan ke DB primer dan pembacaan dari replika. Jika replika tertinggal, data yang baru ditulis belum terlihat.
Mengapa: Penulisan menumpuk di DB primer sehingga replika tertinggal beberapa detik → Akibatnya: Data yang baru disimpan belum ada saat dibaca dari replika → Di layar: Item yang baru dibeli tidak terlihat, harga di market masih nilai lama, bug pemberian ganda
Gejala: Aksi hilang / rollback · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Query melambat saat DB secara berkala menulis sekaligus perubahan yang tersimpan di memori ke disk.
Mengapa: Perubahan menumpuk lalu ditulis ke disk secara berkala → Akibatnya: Saat itu disk sibuk sehingga query melambat → Di layar: Penyimpanan dan loading melambat secara berkala
Gejala: Input lag, Patah-patah · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur)
Setelah DB dimulai ulang, cache di memori kosong, sehingga untuk sementara semua pembacaan data diambil dari disk.
Mengapa: DB dimulai ulang karena maintenance → Akibatnya: Data yang sering dipakai tidak ada di memori sehingga dibaca dari disk → Di layar: Login dan loading lambat untuk sementara tepat setelah maintenance
Gejala: Tidak bisa masuk / loading tanpa henti, Input lag · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika memuat satu karakter butuh puluhan query terpisah, login bersamaan puluhan ribu pemain berubah menjadi jutaan query.
Mengapa: Saat memuat karakter, item, skill, dan quest diambil dengan query terpisah satu per satu → Akibatnya: Tepat setelah maintenance, login bersamaan membuat jumlah query melonjak → Di layar: Loading tanpa henti saat login, penyimpanan pemain yang sedang bermain pun ikut tertunda
Gejala: Tidak bisa masuk / loading tanpa henti, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Agregasi ranking, pengiriman mail massal, dan pembersihan data lama yang dijalankan saat layanan berjalan menahan lock dan menyita kapasitas disk.
Mengapa: Pekerjaan berskala besar dijalankan pada jam layanan → Akibatnya: Lock dengan cakupan luas, disk dan CPU tersita → Di layar: Trade dan penyimpanan gagal pada jam tertentu, loading tertunda
Gejala: Input lag, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Selama DB primer mati dan layanan dialihkan ke DB cadangan, penulisan tidak bisa dilakukan, dan data terakhir yang belum sempat direplikasi bisa hilang.
Mengapa: DB primer mengalami gangguan sehingga DB cadangan dipromosikan → Akibatnya: Selama peralihan, penulisan tidak bisa dilakukan selama beberapa detik hingga beberapa menit; dengan replikasi asinkron, data yang belum direplikasi bisa hilang → Di layar: Semua penyimpanan gagal sesaat, item dan EXP kembali ke kondisi sebelumnya (rollback)
Gejala: Aksi hilang / rollback, Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika data hanya disimpan beberapa menit sekali untuk mengurangi beban, progres akan hilang saat server mati di antara dua penyimpanan.
Mengapa: State karakter disimpan sekali setiap beberapa menit → Akibatnya: Di sela waktu itu server crash atau mengalami gangguan → Di layar: Setelah login ulang, karakter kembali ke kondisi beberapa menit sebelumnya (rollback)
Gejala: Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Jika cache data populer kedaluwarsa bersamaan, ribuan request menyerbu DB sekaligus.
Mengapa: Data populer yang disimpan di Redis dan sejenisnya kedaluwarsa bersamaan → Akibatnya: Request yang ingin membuat ulang data yang sama menyerbu DB sekaligus → Di layar: DB kelebihan beban sehingga banyak fitur satu per satu melambat atau berhenti merespons
Gejala: Input lag, Freeze, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Transaksi yang terbuka lama terus memegang lock, dan DB tidak bisa membersihkan data versi lama (purge), sehingga seluruh DB makin lama makin lambat.
Mengapa: Menunggu respons server lain sambil membiarkan transaksi terbuka, atau menjalankan query agregasi panjang di DB primer saat layanan berjalan → Akibatnya: Lock yang dipegang tidak dilepas, dan data versi lama yang harus dibersihkan terus menumpuk → Di layar: Fitur yang memakai baris itu timeout, penyimpanan dan pembacaan data melambat secara umum selama beberapa jam
Gejala: Input lag, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Redis memproses perintah satu per satu, sehingga satu perintah lambat menahan semua request di belakangnya.
Mengapa: Saat layanan berjalan, seluruh key dicari dengan KEYS, atau ranking dan list berisi jutaan elemen dibaca atau dihapus sekaligus → Akibatnya: Semua request lain menunggu sampai perintah itu selesai (puluhan ms hingga beberapa detik) → Di layar: Fitur yang memakai sesi, ranking, dan cache tersendat sesaat secara bersamaan, login tertunda
Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Walaupun kodenya tidak berubah, jika DB mengganti cara memproses query yang sama (query plan), query yang kemarin 2 ms bisa menjadi ratusan ms hari ini.
Mengapa: Pembaruan statistik otomatis, restart DB, atau perubahan distribusi data membuat DB menyusun query plan baru → Akibatnya: Plan yang tidak memakai indeks terpilih, sehingga query yang sama menjadi puluhan hingga ratusan kali lebih lambat dan koneksi tertahan → Di layar: Tanpa ada deploy, loading fitur tertentu tiba-tiba melambat dan request lain ikut menunggu
Gejala: Input lag, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika kolom atau indeks ditambahkan ke tabel saat layanan berjalan, satu lock yang dibutuhkan sesaat bisa membuat semua request yang memakai tabel itu menunggu.
Mengapa: Hotfix menambahkan kolom atau indeks ke tabel yang sedang dipakai layanan → Akibatnya: Perubahan skema menunggu transaksi panjang yang sudah terbuka lebih dulu, dan semua request yang datang sesudahnya menunggu perubahan skema itu → Di layar: Fitur yang memakai tabel itu (inventory, mail, dan sebagainya) berhenti total lalu timeout
Gejala: Input lag, Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur DB (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
MMO masa kini umumnya terdiri dari server login, gateway, field, dungeon, chat, party, balai lelang, cache, dan DB yang saling memanggil. Jika satu bagian mengalami gangguan, gangguan itu menjalar ke bagian yang terhubung, dan pekerjaan operasional seperti deploy, scaling, dan maintenance juga bisa menimbulkan lag.
Memecah server bisa mencegah gangguan di satu bagian menjalar ke seluruh sistem, tetapi muncul rantai pemanggilan (server memanggil server lain secara berurutan). Misalnya, server game memanggil server balai lelang, lalu server balai lelang memanggil cache dan DB. Jika server di ujung rantai melambat, server-server di depannya terus menahan thread dan koneksi sambil menunggu respons, dan akhirnya fitur yang tampak tidak berkaitan pun ikut berhenti. Ini disebut kegagalan berantai, dan penjalarannya dicegah dengan timeout serta circuit breaker (mekanisme yang memblokir sementara pemanggilan yang terus gagal).
Pekerjaan operasional juga menjadi penyebab lag. Restart saat deploy update, beberapa menit yang dibutuhkan untuk menambah server secara otomatis saat pemain membludak, proses memindahkan karakter ke server lain saat pindah zona, serta beban tak terlihat dari bot dan makro semuanya tampak sebagai “lag” bagi pemain.
Arsitektur server adalah perusahaan yang departemen-departemennya saling mengirim dokumen untuk disetujui. Jika satu departemen di ujung jalur persetujuan (DB) lambat, departemen sebelumnya mengantre sambil memegang dokumen, dan akhirnya pekerjaan seluruh perusahaan berhenti. Timeout adalah aturan “jika tidak ada jawaban lebih dari 10 menit, kembalikan dulu dokumennya”, sedangkan circuit breaker adalah aturan “jika pengembalian terus terjadi, untuk sementara jangan kirim dokumen ke departemen itu dan langsung kembalikan”.
Jika ada server perantara di antara klien dan server game, setiap kali paket melewatinya ada tambahan waktu pemrosesan, dan server itu menjadi single point of failure.
Mengapa: Arsitektur klien ↔ gateway ↔ server game → Akibatnya: Ada tambahan pemrosesan dan antrean di server perantara; saat kelebihan beban, semua pemain terdampak → Di layar: Ping semua pemain naik; saat gateway mengalami gangguan, semua pemain yang melewatinya disconnect
Gejala: Input lag, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Saat masuk ke area atau dungeon lain, keterlambatan dan kegagalan bisa terjadi dalam proses memindahkan data karakter ke server lain.
Mengapa: Server yang menangani karakter berganti saat masuk dungeon atau pindah benua → Akibatnya: Simpan → kirim → muat; jika server tujuan padat atau tidak ada instance dungeon yang kosong, harus menunggu → Di layar: Loading lama, gagal masuk, disconnect saat berpindah
Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect, Rubber banding · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika satu layanan melambat, server yang memanggilnya ikut tertahan menunggu respons, dan fitur yang tidak berhubungan pun ikut berhenti.
Mengapa: Satu layanan, seperti DB atau autentikasi, melambat → Akibatnya: Thread dan koneksi server pemanggil tertahan menunggu respons, dan retry dari permintaan yang gagal menambah beban → Di layar: Fitur yang tampak tidak berhubungan pun ikut melambat atau berhenti
Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Jika server yang berjalan terpisah dari server game, seperti server chat, party, atau balai lelang, mengalami gangguan, hanya fitur itu yang tidak berfungsi.
Mengapa: Server khusus fitur melambat atau mati → Akibatnya: Hanya permintaan untuk fitur itu yang tidak mendapat respons → Di layar: Chat tidak jalan, undangan party tidak direspons, market loading tanpa henti (pertempuran tetap normal)
Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika koneksi tidak dipindahkan saat server dimulai ulang untuk update, pemain di server itu disconnect, lalu penyimpanan data menjelang shutdown dan reconnect membanjir sekaligus.
Mengapa: Server dimulai ulang satu per satu untuk deploy hotfix → Akibatnya: Server dimatikan tanpa memindahkan koneksi ke server lain, penyimpanan data semua pemain di server itu membanjiri DB → Di layar: Disconnect tanpa pengumuman, lonjakan reconnect
Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Saat pemain membanjir, server ditambah secara otomatis, tetapi persiapannya butuh beberapa menit, dan selama itu server yang ada kelebihan beban.
Mengapa: Koneksi melonjak saat event dimulai → Akibatnya: Butuh beberapa menit sampai server baru menyala dan siap → Di layar: Slow motion dan tidak bisa masuk selama beberapa menit tepat setelah event dimulai
Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Saat terjadi gangguan, log melonjak, dan server yang mengirim log secara sinkron menjadi makin lambat karena log itu sendiri.
Mengapa: Error terjadi, volume kirim log dan metrik melonjak → Akibatnya: Pengumpul log tertinggal, dan server yang mengirim secara sinkron ikut menunggu → Di layar: Saat gangguan, patah-patah dan freeze menjadi lebih parah karena log
Gejala: Patah-patah, Freeze · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika jam di setiap server sedikit berbeda, keputusan cooldown, buff, dan waktu mulai event tidak sama antarserver.
Mengapa: Jam server yang sinkronisasi waktunya berhenti selisih ratusan ms hingga beberapa detik dengan server lain → Akibatnya: Jika waktu absolut, seperti waktu berakhirnya buff, dikirim antarserver, keputusannya meleset → Di layar: Setelah berpindah, buff hilang atau cooldown mulai lagi dari awal
Gejala: Aksi hilang / rollback · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Bot mengirim permintaan jauh lebih sering daripada manusia sehingga menggerogoti throughput server.
Mengapa: Banyak bot terhubung dan mengulang berburu, berpindah, dan trade tanpa henti → Akibatnya: Throughput server dan beban DB naik → Di layar: Area berburu tertentu atau seluruh server melambat (slow motion, input lag)
Gejala: Slow motion, Input lag · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur jaringan (Tim Infrastruktur)
Jika layanan eksternal seperti login platform, pembayaran, atau verifikasi identitas lambat atau berhenti, proses tertahan di tahap itu.
Mengapa: Gangguan atau keterlambatan di layanan autentikasi atau pembayaran eksternal → Akibatnya: Tahap itu menunggu respons → Di layar: Tidak bisa login, pembayaran gagal. Pemain yang sudah di dalam game baik-baik saja
Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback · Penanggung jawab utama Pihak Eksternal (Pihak Eksternal) · Turut terlibat Pengembangan server (Tim Pengembang Game)
Jika pemain ditempatkan di server region yang jauh padahal ada region yang dekat, ping pemain itu selalu tinggi walaupun koneksinya baik-baik saja.
Mengapa: Data GeoIP salah, VPN, seluruh party ditempatkan berdasarkan rata-rata ping anggotanya, aturan yang memperluas pencarian ke region jauh saat pemain kurang, penempatan berdasarkan lokasi DNS resolver → Akibatnya: Terhubung ke server region di seberang laut padahal ada region yang dekat → Di layar: Di game yang punya server di beberapa region, hanya Anda (atau hanya party Anda) yang ping-nya selalu tinggi, disertai input lag, rubber banding, dan skill tidak keluar
Gejala: Input lag, Rubber banding, Aksi hilang / rollback · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal)
Jika sertifikat server login, API, atau patch kedaluwarsa atau sertifikat perantaranya tidak disertakan, koneksi TLS dari klien yang baru tersambung gagal sejak saat itu.
Mengapa: Masa berlaku sertifikat sudah lewat, server mengirim tanpa sertifikat perantara, atau tanggal dan jam di perangkat pemain salah → Akibatnya: Klien gagal memverifikasi sertifikat dan memutus koneksi TLS → Di layar: Tidak bisa masuk atau loading tanpa henti di tahap login atau patch, atau hanya fitur HTTPS seperti toko yang gagal. Pemain yang sudah terhubung biasanya baik-baik saja
Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Jika koneksi membanjir tepat setelah rilis atau maintenance, antrean login mencapai batas dan menolak antrean baru, sementara pemain yang sedang menunggu kehilangan tempatnya saat koneksinya terputus sebentar dan kembali ke urutan paling belakang.
Mengapa: Orang yang ingin masuk lebih banyak daripada kapasitas yang bisa diterima server login sekaligus, sehingga dibuat antrean, dan jika antrean terlalu panjang, antrean baru ditolak untuk melindungi server → Akibatnya: Makin panjang antrean, makin lama waktu tunggu, dan selama itu Wi-Fi atau jaringan seluler yang terputus sebentar saja sudah membuat tempat di antrean hilang → Di layar: Tidak bisa masuk atau loading tanpa henti, game tertutup dengan error saat menunggu, harus mengantre lagi dari belakang
Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur)
Saat menerima laporan lag, cukup pilih tiga hal: “siapa, kapan, dan seperti apa bentuknya”. Asisten ini menampilkan kandidat penyebab dari buku putih ini yang paling cocok, diurutkan berdasarkan skor. Hasilnya belum diagnosis pasti, tetapi sudah cukup untuk menentukan tim mana yang ditanya lebih dulu.
Saat laporan atau alert masuk, persempit masalahnya dengan urutan cakupan → waktu → lapisan. Lokasi menumpuknya anomali paling menentukan tim penanggung jawabnya, kejadian yang bersamaan dengannya mempersempit penyebabnya, dan lapisan yang metriknya tidak normal menjadi konfirmasinya. Jika “Di grafik” dan “Cara memastikan” di setiap kartu penyebab dipakai bersama, Anda bisa memilih kandidat dari pola grafik dan langsung tahu bagian yang perlu diperiksa.
Di mana anomali menumpuk?
Bersamaan dengan apa?
Metrik lapisan mana yang tidak normal?
| Yang diperiksa | Jika terlihat seperti ini | Pihak yang dihubungi pertama |
|---|---|---|
| Antrean terima socket server (Recv-Q) | Proses server tidak sempat membacanya tepat waktu sehingga data menumpuk | Tim Pengembang GameServer (tick terhenti, GC, lock) |
| Retransmisi dan RTT per koneksi | Hanya sebagian koneksi, terpusat di ASN tertentu | Tim InfrastrukturJaringan Pihak EksternalISP/koneksi pemain |
| Semua koneksi di satu host | Tim InfrastrukturServer/OS (NIC, kernel) | |
| Retransmisi dan bandwidth seluruh server naik tepat setelah patch | Ukuran dan frekuensi paket berubah | Tim Pengembang GameServer Tim InfrastrukturJaringan (MTU, batas) |
| CPU steal, throttling, softirq, drop di NIC | Naik | Tim InfrastrukturServer/OS |
| Hanya satu thread di 100%, waktu tunggu run queue, jeda GC | Naik | Tim Pengembang GameServer |
| Latensi DB naik, jumlah query tetap | IOPS, lock, pekerjaan lain | Tim InfrastrukturServer DB |
| Jumlah dan bentuk query DB berubah setelah patch | N+1, query baru | Tim Pengembang GameServer |
| Synthetic monitoring dari titik ukur di luar negeri (RTT, packet loss) | Buruk | Tim InfrastrukturJaringan Pihak EksternalISP |
| Synthetic monitoring normal, tetapi hanya data pemain yang buruk | Lingkungan pemain atau klien | Pihak EksternalLingkungan pemain Tim Pengembang GameKlien |
| Distribusi alasan koneksi terputus | Heartbeat timeout↑ / RST↑ / diputus server↑ | NAT dan rute / perangkat / server |
| Periode yang presisi (tepat di awal jam, setiap N menit) | Tugas terjadwal, backup, GC, event | Pihak yang membuat jadwal itu |
Cukup dengan mengenali pola grafik monitoring, kandidat penyebab sudah jauh berkurang. Di bawah ini ada 13 pola, masing-masing dengan daftar penyebab yang menghasilkannya. Gambar kecil di kartu penyebab menunjukkan pola yang sama. Garis solid adalah metrik utama, garis putus-putus adalah metrik pendamping (jumlah pemain, waktu tunggu, error, dan sebagainya), dan garis putus-putus samar adalah level normal.
Biasanya rendah, lalu melonjak dengan selang yang sama, misalnya setiap beberapa detik, setiap beberapa menit, atau tepat di awal jam.
Garbage collection di klien, Pemindaian oleh modul keamanan game (anti-cheat), Pemindaian Wi-Fi di latar belakang, Tugas terjadwal, Timer terpicu serentak, Jeda GC stop-the-world di server, Jeda GC di engine skrip, Lonjakan fsync, Tugas backup, kompresi, dan pemindaian, Checkpoint dan log flush, Batch job berskala besar, Cache stampede
Melonjak tidak beraturan tanpa selang yang tetap, lalu segera kembali normal.
Lonjakan frame time, Ekstrapolasi berlebihan (dead reckoning), Prediksi sisi klien meleset, Catch-up fixed timestep yang lepas kendali, Pemakaian CPU oleh proses di latar belakang, Kekurangan memori dan swap di klien, Mode hemat daya NIC dan masalah driver, Interferensi Wi-Fi dan sinyal lemah, Perpindahan 5G↔LTE yang sering (di tepi jangkauan 5G), Kualitas koneksi buruk, Ring buffer terlalu kecil, Overhead virtualisasi dan noisy neighbor, Buffer socket kernel terlalu kecil, CPU steal (virtual machine), Jeda akibat reclaim dan compaction memori, Lompatan jam sistem (NTP step), Pengiriman blocking akibat klien lambat, Pengaturan retransmisi reliable UDP, Data terakhir hilang akibat penutupan paksa dengan RST, Pemanggilan sinkron di thread game, Penulisan log sinkron, Lazy loading di server, Deadlock DB, Perintah lambat di Redis, Beban berlebih akibat log dan monitoring, Lockstep menunggu pemain paling lambat, Prediksi rollback netcode meleset, Event diputar begitu tiba tanpa timestamp, Validasi server yang terlalu ketat, Perhitungan jalur tidak sama pada sinkronisasi perintah, Urutan pendaftaran jarak pandang kacau, Snapshot baseline hilang, Pesan despawn hilang (objek hantu), Kekeliruan akibat ID objek dipakai ulang, Retransmisi yang tidak perlu akibat lonjakan latensi
Naik satu tingkat sejak waktu tertentu, seperti patch, perubahan konfigurasi, atau perubahan rute, lalu bertahan di level itu.
Gangguan kabel bawah laut dan jalur internasional, Perubahan rute dan konvergensi BGP, Rute lewat proteksi DDoS dan false positive, Perubahan performa setelah update OS, kernel, driver, atau firmware, Pola trafik berubah akibat patch, Query tanpa indeks, Query melambat karena query plan berubah, Lock akibat perubahan skema (DDL) saat layanan berjalan, Ketergantungan pada layanan eksternal, Perubahan rute dan jalur ECMP bermasalah
Naik sedikit demi sedikit selama beberapa jam atau beberapa hari. Makin lama menyala, makin tinggi.
Kesalahan sinkronisasi jam, Hilangnya presisi waktu bertipe float, Kebocoran memori di klien, Mode hemat daya dan thermal throttling, Kebocoran memori, Swap, Fragmentasi memori, Disk penuh, Transaksi yang terbuka lama, Selisih jam antarserver
Naik perlahan, lalu anjlok saat restart atau pembersihan, dan pola ini berulang.
Laju kirim anjlok akibat congestion control, Penumpukan objek (item dan summon yang tidak dibersihkan)
Naik membentuk bukit hanya pada jam yang sama setiap hari, misalnya jam sibuk malam.
Channel Wi-Fi padat, Kongesti di jalur peering saat jam sibuk, False positive validasi yang terpusat pada pemain ISP tertentu, Antrean bottleneck meluap (packet loss akibat kongesti)
Saat jumlah pemain online bersamaan atau pemain yang berkumpul di satu tempat bertambah, grafik ikut naik dengan lebih curam.
Beban rendering kerumunan besar, Bottleneck pemrosesan paket di main thread, Buffer terima meluap, Pemakaian bandwidth oleh aplikasi lain di perangkat yang sama, Bufferbloat (antrean router), Microburst di switch, Thread berlebihan dan context switching, CPU throttling di container (kuota CFS), Fragmentasi IP pada paket UDP, Arsitektur I/O blocking, Tick melewati budget (tick overrun), Lonjakan perhitungan jarak pandang (AOI, N²), Lonjakan broadcast, Kelebihan beban di area single-thread (hotspot), Perebutan lock, Lonjakan pathfinding, Biaya serialisasi dan kompresi, Pertempuran terpusat pada satu target (world boss), Lonjakan alokasi, Perebutan lock pada hot row, Replication lag, Rute lewat gateway atau proxy, Pindah zona (handoff antarserver), Budget pengiriman dan prioritas per koneksi, Buffer dangkal meluap akibat burst pengiriman, Duplex mismatch
Throughput atau jumlah koneksi tidak bisa naik lagi setelah mencapai nilai tertentu, dan sejak itu antrean dan error bertambah.
Kekurangan memori grafis (VRAM), Router kurang bertenaga atau terlalu panas, Pembatasan kecepatan dan manajemen trafik oleh ISP, Jalur bersama penuh akibat DDoS, Tabel sesi firewall penuh, Batas koneksi dan port NAT gateway cloud, Jalur data center penuh, Interrupt NIC terpusat di satu core, Batas PPS cloud terlampaui, Bandwidth NIC penuh, Batas file descriptor, Tabel conntrack server penuh, Port ephemeral habis pada koneksi antarserver, Penumpukan antrean pesan, Thread pool habis, GC thrashing (heap hampir penuh), Burst credit disk cloud habis, Batas IOPS dan antrean jenuh, Connection pool habis, Kegagalan berantai, Batas antrean login dan masa tenggang reconnect yang terlalu singkat, Streaming gagal akibat kekurangan memori atau VRAM, Policer membuang trafik berlebih, Paket dibuang di host server penerima, Paket dibuang oleh firewall atau connection tracking, Batas pemrosesan perangkat perantara terlampaui (firewall, IPS, proteksi DDoS)
Terus bertahan di nilai tinggi tanpa lonjakan. Penyebabnya struktural, seperti jarak, rute, atau desain.
Buffer interpolasi tidak ada atau terlalu pendek, V-Sync dan antrean render, Resolusi timer, Latensi layar, perangkat input, dan frame generation, Latensi propagasi (jarak fisik), Routing memutar, Interrupt coalescing berlebihan, Jeda tunggu penggabungan GRO/LRO, Lonjakan latensi akibat manajemen daya server (C-state, pengaturan frekuensi), Algoritma Nagle + delayed ACK, Cache miss, Latensi seek HDD, Feedback baru tampil setelah server merespons (model request-response), Protokol dengan banyak round trip berurutan (chatty), Tidak ada input buffering untuk skill, Otoritas klien, Menunggu tick dua kali, Laju pengiriman snapshot rendah, Fast retransmit yang tidak perlu akibat urutan paket tertukar, Pengaturan RTO tidak sesuai dengan lingkungan, Opsi TCP dihapus oleh perangkat perantara
Sebagian besar normal; hanya pemain, wilayah, ISP, atau perangkat tertentu yang tinggi sendiri.
Streaming aset tertinggal akibat storage lambat, Crash di klien, Pemeriksaan paket oleh program keamanan, Interferensi program overlay, Jeda transisi state RRC (hemat daya radio seluler), Sinyal seluler lemah dan area blank spot, Pembatasan di Wi-Fi publik dan jaringan kantor, Internet satelit (orbit rendah dan geostasioner), Satu jalur ECMP bermasalah, Pembatasan UDP dan inspeksi paket per negara atau ISP, Gangguan dan latensi DNS, Rute lewat VPN atau game booster, Distribusi load balancer timpang dan health check keliru, Kabel rusak dan error port, MTU tidak cocok (hanya paket besar yang hilang), Kebijakan penanganan klien lambat (slow consumer), Nilai default keepalive 2 jam, Slow start setelah idle, Distribusi SO_REUSEPORT tidak merata, Akses memori NUMA remote, Terlalu banyak macro dan bot, Kesalahan matchmaking dan penempatan region, Timing window pendek yang termakan ping, Hit registration tanpa lag compensation, Lag compensation berlebihan, Arsitektur host (pembuat room), Server menolak setelah feedback sisi klien, Pemain yang lag terlihat fast forward di layar pemain lain, Fast forward pada server yang memproses input begitu tiba, Ukuran buffer input per pemain, Satu anggota party yang lambat dan mekanik boss, Otoritas kontrol monster ada di klien yang lambat, Data karakter tertentu terlalu besar, Perbedaan channel, instance, atau phasing, Pesan spawn yang tiba saat loading dibuang, Bentrok port UDP tetap, Bug pembedaan sesi berdasarkan IP atau perangkat, Pembatasan multi-klien, Bentrok akses bersamaan ke file cache dan aset, Perbedaan opsi tampilan, Versi klien atau data tidak cocok, Objek ditahan akibat kesalahan estimasi jam, Packet loss di jalur nirkabel, Error fisik (kabel, modul optik, atau konektor rusak), MTU black hole (hanya paket besar yang berulang kali hilang), ACK terlambat atau hilang (upload penuh)
Jumlah data yang diterima turun ke 0 selama beberapa saat, lalu datang menumpuk sekaligus.
Pemrosesan dibatasi saat jendela diminimalkan atau tidak aktif, Handover antar-BTS (saat bergerak), Maintenance host cloud dan live migration, Masalah driver dan firmware NIC, HOL blocking pada TCP, RTO TCP dan exponential backoff, Pemrosesan dibatasi di jendela latar belakang, Pemulihan lambat pada thin stream, Zero window (jeda yang terlihat seperti retransmisi)
Jumlah koneksi anjlok, atau jumlah disconnect melonjak seketika.
Aplikasi mobile masuk ke latar belakang, Perpindahan Wi-Fi ↔ LTE/5G, Mapping NAT kedaluwarsa, IP bersama dari ISP (CGNAT), Idle timeout load balancer, Connection tracking di security group cloud kedaluwarsa, Failover perangkat jaringan, OOM killer, Error WSAECONNRESET pada socket UDP Windows, Deadlock, Crash di server, Infinite loop dan logika lepas kendali, Penulisan core dump, Failover DB, Progres hilang karena interval penyimpanan yang panjang, Gangguan server pendukung, Deploy dan restart, Sertifikat TLS kedaluwarsa atau salah konfigurasi, Mapping NAT atau load balancer kedaluwarsa di tengah koneksi
Melonjak tinggi tepat setelah server dibuka atau event dimulai, lalu turun perlahan.
Pemuatan sinkron dan kompilasi shader di main thread, Antrean koneksi (backlog) meluap, Lonjakan spawn saat masuk area padat, Cold cache (tepat setelah restart), Lonjakan login dan N+1 query, Keterlambatan autoscaling, Data spawn hilang saat membanjir tepat setelah masuk zona, Retransmisi permintaan koneksi (SYN)
Bagian ini menghitung sarana pemeriksaan termudah untuk setiap penyebab. Tools infrastruktur berarti penyebab bisa dipastikan dengan tools OS, jaringan, cloud, dan DB serta opsi startup runtime (log GC dan sebagainya), tanpa mengubah kode game. Log/metrik game adalah data yang baru terlihat jika game mencatatnya, seperti waktu tick dan alasan koneksi terputus. Makin banyak penyebab di kolom ini pada suatu lapisan, makin kuat dasar untuk meminta instrumentasi ke Tim Pengembang Game.
Rata-rata menyembunyikan lonjakan. Pada server 20 tick per detik, jika 1% tick saja melambat, semua pemain tersendat sesaat kira-kira sekali setiap 5 detik, tetapi rata-rata waktu tick hampir tidak berubah. Karena itu, persentil juga perlu diperiksa. p50 (median) adalah nilai yang separuh sampelnya lebih cepat darinya, sedangkan p99 adalah nilai di sekitar 1 sampel paling lambat dari 100. Yang diingat pemain sebagai “lag” biasanya ada di sekitar p99.
Interval agregasi juga menyembunyikan lonjakan. Di grafik rata-rata 1 menit, jeda 1 detik memudar menjadi 1/60. Saat mencari jeda, periksa juga nilai maksimum atau p99 di grafik yang sama, serta grafik dengan interval yang lebih pendek.
Jitter adalah seberapa besar variasi selang waktu kedatangan paket. Meskipun rata-rata ping rendah, jitter yang besar membuat buffer interpolasi kosong sehingga terjadi patah-patah dan teleport.
| Cara mengukur | Yang diukur | Yang perlu diperhatikan |
|---|---|---|
ping (ICMP) | Waktu pulang-pergi sampai ke perangkat tujuan | Router dan server bisa menunda pemrosesan respons ICMP atau membatasi jumlahnya, sehingga hasilnya bisa berbeda dari paket game. Jika ICMP diblokir, tidak ada respons sama sekali |
mtr·traceroute | Latensi dan packet loss per hop | Jika hanya satu perangkat di tengah yang packet loss-nya tinggi dan hop sesudahnya normal, besar kemungkinan perangkat itu hanya membatasi respons ICMP. Packet loss sungguhan hanyalah packet loss yang berlanjut sampai tujuan akhir |
TCP RTT (rtt pada ss -ti) | Waktu pulang-pergi yang diukur kernel untuk setiap koneksi | Paling bisa dipercaya karena berasal dari koneksi game yang sebenarnya. Bisa dilihat per pemain dari sisi server |
| Ping di dalam game | Waktu pulang-pergi yang diukur game dengan pesannya sendiri | Jika diukur di dalam game loop, waktu tunggu frame dan tick ikut tercampur. Nilainya naik saat server atau PC sibuk meskipun koneksinya baik-baik saja |
ss -ti atau tools eBPF, lalu lihat per ASN.pidstat -t), waktu tunggu run queue, dan log GC yang cukup diaktifkan lewat opsi startup.mtr.Bagian ini berisi urutan pemeriksaan untuk dua situasi yang sering dihadapi, serta kasus insiden nyata yang dipublikasikan sendiri oleh pengembang asli atau operator game. Setiap langkah dan kasus terhubung ke kartu penyebab terkait.
Saat laporan lag bertambah sejak patch atau deploy tertentu. Pakai prosedur ini saat laporan seperti “sejak update ini jadi aneh” mulai berdatangan, atau saat grafik naik seperti anak tangga pada suatu waktu lalu bertahan di level itu.
Saat membuka layanan di negara baru atau menambah region atau data center baru. Pakai juga untuk pemeriksaan sebelum peluncuran dan untuk memilah laporan seperti “di Korea lancar, tetapi hanya pemain di negara baru yang lag”.
Hanya postmortem yang dipublikasikan sendiri oleh perusahaan game dan perusahaan infrastruktur yang dipilih. Ringkasannya ditulis dalam batas yang diungkapkan sumber asli; untuk kronologi lengkapnya, baca sumber aslinya.
Dalam pertempuran armada besar di sistem bintang HED-GP yang dibahas tulisan retrospektif Januari 2014, server mengalami kelebihan beban yang parah. Bahkan setelah Time Dilation (fitur yang memperlambat waktu game saat kelebihan beban) mencapai batas bawahnya, yaitu 10%, dan seluruh medan pertempuran menjadi slow motion, beban terus menumpuk. Keterlambatan pekerjaan yang memproses penghentian dan siklus berulang modul (Dogma Lateness) mencapai puncak 193 detik waktu game, atau sekitar 32 menit waktu nyata. Pertempuran 6VDT pada Juli 2013, yang skalanya hampir sama, mencapai puncak 42 detik (sekitar 7 menit waktu nyata). CCP menegaskan bahwa penyebabnya belum bisa dipastikan, karena tools analisis performa ikut menambah beban sehingga tidak dijalankan dalam situasi seperti ini. Dengan catatan itu, CCP menyebut dua penyebab yang paling mungkin. Pertama, beban yang tidak sempat diproses terus menumpuk selama pertempuran berlangsung lama. Kedua, penggunaan drone meningkat: jumlah drone unik yang dikerahkan selama pertempuran mencapai 21.123 di 6VDT dan 38.852 di HED-GP, atau 84% lebih banyak. Aksi seorang pemain harus diberitahukan kepada semua orang yang melihatnya, sehingga jumlah pengiriman tumbuh sebanding dengan kuadrat jumlah pemain (O(n²)), dan drone menghasilkan lebih banyak pesan untuk setiap serangan. Kode yang dipakai drone untuk memilih target juga sering memeriksa semua target yang bisa diserang di medan pertempuran yang sama, sehingga biayanya tumbuh mendekati n².
Jika throughput satu area yang dipadati pemain melewati batasnya, seluruh area itu menjadi slow motion. Makin lama pertempuran berlangsung, makin banyak pemrosesan tertunda yang menumpuk, dan input lag makin besar. Sinyal yang perlu diperiksa adalah waktu tick dan jumlah pekerjaan tertunda di server (node) yang menangani area itu, serta jumlah pemain dan objek. Cirinya, area lain tetap normal. Penanggung jawab utama adalah Tim Pengembang Game (server), dan yang perlu diperbaiki adalah cakupan penerima pemberitahuan untuk satu aksi serta biaya pencarian target oleh AI. Desain yang memperlambat waktu game tidak menghilangkan kelebihan beban. Namun, desain ini membuat semua pemain melambat dengan kecepatan yang sama, sehingga tidak ada aksi tertentu yang tertunda tanpa batas. Sumber asli
Tulisan teknis Riot Games yang menjelaskan mengapa internet tidak cocok untuk game real-time. Trafik nyata yang dilaporkan seorang pemain League of Legends seharusnya berjalan langsung dari San Francisco ke Portland, tetapi malah melewati Los Angeles, Denver, dan Seattle, sehingga perjalanan yang cukup 14 ms jika langsung menjadi 70 ms. Riot menjelaskan bahwa jika router meluap dan paket dibuang, champion lain terlihat melompat-lompat di layar dan proyektil terlihat teleport. Riot menyebut rute dan router sebagai penyebabnya. Penyedia backbone dan ISP mengirim trafik lewat rute yang biayanya paling murah, yang belum tentu rute dengan latensi terendah, dan jika rute yang ditentukan BGP memutar jauh, jumlah router yang dilewati juga bertambah. Beban pemrosesan router bergantung pada jumlah paket, berapa pun ukurannya. Paket game berukuran sekitar 55 byte, sehingga untuk volume data yang sama jumlahnya 27 kali lipat paket 1.500 byte dan buffer input router pun lebih cepat penuh. Menurut penjelasan Riot, banyak router juga membuang paket UDP lebih dulu saat kelebihan beban. Sebagai solusinya, Riot membangun jaringan sendiri bernama Riot Direct dengan menempatkan router di 10 hub internet besar di Amerika Serikat dan terhubung langsung (peering) dengan sebanyak mungkin ISP. Menurut tulisan bagian kedua, porsi pemain yang bermain dengan ping di bawah 80 ms naik dari 31% menjadi 50% dalam sedikit lebih dari 9 bulan, lalu menjadi 80% dalam semalam setelah server game dipindahkan ke Chicago.
Jika hanya pemain dari ISP tertentu yang ping-nya jauh lebih tinggi, bahkan di dalam satu negara, curigai rutenya. Sinyal yang perlu diperiksa adalah distribusi RTT per ISP (ASN) dan kota transit yang muncul di traceroute. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), dan perbaikannya lewat peering langsung dengan ISP, koneksi ke IX, dan pemilihan lokasi server. Kebijakan rute di sisi ISP perlu dibicarakan dengan Pihak Eksternal (ISP). Kasus ini juga menunjukkan bahwa memindahkan server lebih dekat ke pusat sebaran pemain saja sudah memberi dampak besar. Sumber asli
Pada akhir Februari 2020, server League of Legends EUW, EUNE, dan BR beberapa kali mengalami gangguan, dan jumlah game baru yang dimulai turun tajam. Semua layanan backend seperti matchmaking dan server game berstatus normal, tetapi hampir tidak ada trafik yang masuk. Riot menunda jadwal mode turnamen (Clash) selama satu minggu agar tidak membukanya di cluster yang mungkin tidak stabil. Tulisan retrospektifnya tidak mencantumkan berapa lama setiap gangguan berlangsung. Tiga hal terjadi bersamaan. Request ke satu layanan dibuat dengan keliru sehingga dalam kasus tertentu terus gagal dan terus dicoba ulang, dan jumlah request melonjak. Masalah kompatibilitas yang sudah diketahui antara sistem container dan versi OS membuat memori di dalam OS bocor. Upgrade baru selesai di sekitar 60% seluruh lingkungan container Riot, sedangkan cluster Eropa dan Amerika Latin masih dalam proses. Container edge, yang menerima trafik internet, menyaringnya, lalu meneruskannya ke backend, ditempatkan terpisah di dalam shard (kelompok server) yang sama, tetapi tidak ada yang mencegah container dari shard yang berbeda berkumpul di satu host. Akibatnya, setiap kali gangguan terjadi, container edge dari minimal tiga shard menumpuk di satu host. Lonjakan retry menghantam host itu, lalu kebocoran memori membuat host itu berhenti.
Jika semua layanan backend menjawab “normal, tetapi trafik tidak masuk”, periksa bagian di depannya (edge, gateway, load balancer). Sinyal yang perlu diperiksa adalah jumlah koneksi masuk yang menumpuk di host tertentu, serta rasio kegagalan dan retry untuk request tertentu. Penanggung jawab utama adalah Tim Pengembang Game (server: request yang keliru dan cara retry), sedangkan aturan penempatan container, upgrade OS, dan alert penumpukan ditangani Tim Infrastruktur (server/OS). Riot memperbaiki kode request-nya, mengubah retry agar tidak melonjak, dan memasang alert penumpukan sampai penyebaran ke shard yang berbeda selesai diimplementasikan. Sumber asli
Pada 22 Januari 2021, server League of Legends EUW tidak berfungsi dengan benar selama sedikit lebih dari 5 jam. Metrik jumlah pemain yang login dan jumlah pemain yang sedang bermain terputus bersamaan, dan di antara dua kali restart, jumlah login bertambah tetapi hampir tidak ada game yang dimulai. Server primer dari DB yang menangani fitur tidak penting mengalami kerusakan hardware, dan DB itu tidak dikonfigurasi untuk failover otomatis ke server cadangan. Setiap DB punya connection pool sendiri, tetapi semua pool memakai thread pool yang sama. Pekerjaan yang dikirim ke DB yang rusak tidak pernah selesai dan terus menahan thread, sampai seluruh sistem kehabisan thread. Di tengah banjir alert, tim lebih dulu mencurigai serangan jaringan berbahaya yang baru saja dialami dan pekerjaan hardware di region lain, sehingga alert dari DB yang rusak baru diperhatikan sekitar 1 jam kemudian. Semua sistem berjalan di satu JVM, jadi ketika GC berulang kali menghentikan proses selama beberapa detik di tengah beban reconnect setelah restart, pengumpulan metrik juga mengalami celah besar. Antrean login juga tidak mematuhi batas yang dikonfigurasi, sehingga arus pemain yang masuk naik turun tidak beraturan.
Satu DB pendukung yang dianggap tidak penting pun bisa menghentikan semuanya lewat sumber daya bersama seperti thread pool. Sinyal yang perlu diperiksa adalah jumlah request yang menunggu per DB, utilisasi thread pool, serta rasio game yang dimulai terhadap jumlah login yang terlalu rendah. Penanggung jawabnya Tim Pengembang Game (server: isolasi thread pool dan timeout) dan Tim Infrastruktur (DB: failover otomatis). Saat alert membanjir, orang cenderung lebih dulu mencurigai masalah yang baru saja dialami (misalnya serangan), jadi singkirkan kemungkinan satu per satu sesuai urutan diagnosis (cakupan → waktu → lapisan). Setelah restart, periksa juga apakah antrean login benar-benar membatasi arus masuk sesuai konfigurasi. Sumber asli
Gangguan dimulai pada sore hari 28 Oktober 2021 (waktu Pasifik) dengan beban CPU tinggi di satu server Consul. Pada pukul 16.35, jumlah pemain yang sedang online turun menjadi setengah dari biasanya, lalu seluruh layanan berhenti. Baru pada 31 Oktober pukul 16.45 semua pemain bisa masuk kembali, 73 jam sejak gangguan dimulai. Roblox menyebut layanannya dipakai 50 juta orang setiap hari. Roblox memakai HashiCorp Consul untuk service discovery (fungsi yang dipakai layanan untuk saling menemukan alamat), health check, dan penyimpanan KV, dan satu cluster Consul menangani beberapa workload sekaligus. Ada dua akar penyebab. Pertama, fitur streaming baru di Consul, yang cakupannya diperluas selama beberapa bulan, diaktifkan juga untuk layanan routing trafik sehari sebelum gangguan, dan jumlah node layanan itu ditambah 50%. Di bawah beban baca dan tulis yang sama-sama sangat tinggi, fitur ini menimbulkan perebutan pada satu sumber daya bersama (channel Go). Di server dual socket (NUMA) dengan jumlah core lebih banyak yang dipasang sebagai pengganti selama gangguan, perebutannya makin parah. Kedua, pengelolaan daftar halaman kosong (freelist) di BoltDB, yang dipakai Consul untuk menyimpan log Raft, melambat secara tidak wajar: setiap penambahan data 16 kB atau kurang menulis 7,8 MB ke disk. Median latensi tulis KV yang biasanya di bawah 300 ms menjadi 2 detik, dan zero window (buffer TCP penuh) juga terlihat di server leader yang lambat. Karena telemetri bergantung pada Consul, metrik yang dibutuhkan untuk mencari penyebab ikut hilang.
Jika sistem dasar yang diandalkan banyak layanan sekaligus (service discovery, penyimpanan konfigurasi, autentikasi) melambat, semua fitur berhenti bersamaan. Sinyal yang perlu diperiksa adalah latensi tulis, pergantian leader, dan CPU sistem itu, serta perubahan konfigurasi tepat sebelum gangguan. Penanggung jawabnya kedua tim, yaitu Tim Pengembang Game (server) dan Tim Infrastruktur (server/OS). Monitoring perlu dipisahkan agar tidak bergantung pada sistem yang dipantaunya, supaya metrik tetap bisa dilihat saat gangguan. Saat pemulihan, cache masih kosong sehingga sistem bisa runtuh lagi jika semua pemain masuk sekaligus. Karena itu Roblox mengatur porsi pemain yang boleh masuk lewat DNS dan menaikkannya sekitar 10% setiap tahap. Sumber asli
Sejak early access ekspansi Endwalker pada Desember 2021, setiap World sangat padat. Antrean login memanjang, dan Error 2002 sering muncul saat login dari layar pemilihan karakter atau saat menunggu di antrean. Sebagian World dan zona juga down (Error 3001), dan antrean mengalami timeout (Error 4004). Saat pengumuman 11 Desember, pada hari ke-8 early access, kepadatan masih berlanjut. Error 2002 muncul dalam dua kasus. Kasus pertama terjadi saat jumlah pemain yang menunggu di satu data center logis melebihi 17.000 orang. Ini adalah batas atas untuk mencegah server login down karena antrean terlalu panjang, dan saat batas ini tercapai, klien tertutup sepenuhnya. Pada 7 Desember, hardware cadangan untuk keperluan pengembangan dipasang ke server lobi untuk menaikkan batas itu. Error ini berkurang, tetapi antreannya justru makin panjang. Kasus kedua terjadi saat koneksi pemain yang sedang menunggu tidak stabil. Makin lama waktu tunggu, makin sering koneksi putus sesaat akibat packet loss di jalur internet atau Wi-Fi yang tidak stabil. Server lobi menunggu reconnect selama puluhan detik hingga sekitar 1 menit. Pemain yang tersambung kembali dalam waktu itu melanjutkan dari posisinya di antrean, sedangkan yang melewati batas itu harus mulai lagi dari paling belakang. Square Enix menyebut sebagian besar laporan termasuk kasus ini. Akibat kekurangan chip semikonduktor, World juga tidak bisa langsung ditambah.
Makin panjang antrean, makin sering koneksi yang putus sesaat pada pemain yang sedang menunggu berubah menjadi error koneksi. Dalam kepadatan yang sama, error menumpuk pada pemain yang memakai Wi-Fi atau koneksi tidak stabil, sehingga masalahnya menjadi masalah yang “hanya dialami sebagian pemain”. Sinyal yang perlu diperiksa adalah panjang antrean dan waktu tunggu, serta porsi koneksi yang putus saat menunggu di antrean di antara semua alasan koneksi terputus. Penanggung jawab utama adalah Tim Pengembang Game (server: batas atas antrean dan masa tenggang reconnect), dan Tim Infrastruktur ikut menambah server lobi dan server World. Dengan masa tenggang reconnect yang longgar, koneksi pemain yang putus sesaat lebih jarang berujung pada hilangnya nomor antrean. Sumber asli
Banyak game menyerahkan web, API, dan proteksi DDoS kepada penyedia CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 17 Juli 2020 pukul 21.12–21.39 (UTC), selama 27 menit, trafik di seluruh jaringan Cloudflare turun sekitar 50%. Dampaknya terbatas pada sebagian lokasi di kota-kota Amerika Serikat, Eropa, Rusia, dan Brasil yang terhubung ke backbone. Lokasi lain normal. Gangguan di segmen backbone Newark–Chicago membuat segmen Atlanta–Washington mengalami kongesti, sehingga seorang engineer mengubah konfigurasi router untuk mengurangi trafik backbone di Atlanta. Seharusnya seluruh entri kebijakan (term) dinonaktifkan, tetapi yang dinonaktifkan hanya kondisi di dalamnya (prefix-list). Akibatnya, router Atlanta menyebarkan semua rute BGP ke seluruh backbone dengan prioritas lebih tinggi (local-preference 200). Prioritas yang diberikan setiap lokasi untuk rute ke servernya sendiri adalah 100, sehingga semua trafik dari lokasi yang terhubung ke backbone tersedot ke Atlanta. Atlanta kelebihan beban, sedangkan lokasi yang terdampak hampir tidak punya trafik untuk diproses. Layanan pulih setelah router Atlanta dikeluarkan dari backbone. Cloudflare menyatakan gangguan ini tidak berkaitan dengan serangan atau pembobolan.
Jika hanya pemain di kota atau wilayah tertentu yang serentak mengalami disconnect atau tidak bisa masuk / loading tanpa henti, sementara pemain lain normal, curigai dulu perubahan konfigurasi rute yang baru saja dilakukan. Di grafik, CPU dan trafik melonjak hanya di satu lokasi, sedangkan lokasi yang terdampak justru turun mendekati 0. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), atau Pihak Eksternal jika gangguannya ada di sisi penyedia. Cloudflare memutuskan untuk memasang batas jumlah rute yang boleh diterima setiap sesi BGP backbone (maximum-prefix), dan menyesuaikan prioritas agar satu lokasi tidak bisa menarik trafik lokasi lain. Sumber asli
Banyak game mendistribusikan file patch, launcher, dan halaman web lewat CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Mulai 8 Juni 2021 pukul 09.47 (UTC), 85% jaringan Fastly mengembalikan error. Dalam 49 menit, 95% jaringan kembali normal, dan gangguan selesai ditangani pada pukul 12.35. Deploy software yang dimulai pada 12 Mei mengandung bug yang terpicu saat konfigurasi pelanggan tertentu bertemu kondisi tertentu. Pada 8 Juni, seorang pelanggan mengunggah perubahan konfigurasi yang valid, dan kondisi itu terpenuhi. Fastly mendeteksi anomali dalam 1 menit, dan pemulihan dimulai setelah konfigurasi pelanggan penyebabnya ditemukan dan dinonaktifkan. Deploy perbaikan bug dimulai pada hari yang sama pukul 17.25.
Kode yang sudah di-deploy beberapa minggu sebelumnya pun bisa seketika menjadi gangguan global saat bertemu kondisi langka. Di sisi game, sinyal yang perlu diperiksa adalah tingkat error HTTP untuk request patch, launcher, dan web yang naik serentak di semua wilayah, serta halaman status penyedia CDN. Cirinya, koneksi game yang sudah tersambung tetap normal jika tidak lewat CDN, dan yang terblokir hanya koneksi baru, unduhan patch, dan login web. Penanggung jawab utama adalah Pihak Eksternal (penyedia CDN), sedangkan Tim Pengembang Game dan Tim Infrastruktur menyiapkan rute cadangan, misalnya memakai lebih dari satu CDN atau mengambil langsung dari server origin. Sumber asli
Gangguan infrastruktur yang pelajarannya berlaku juga untuk jaringan dan DNS milik perusahaan game sendiri. Pada 4 Oktober 2021, layanan Facebook (kini Meta) tidak bisa diakses di seluruh dunia. Backbone yang menghubungkan data center-nya terputus seluruhnya, dan server DNS Facebook tidak bisa ditemukan dari internet. Tulisan retrospektifnya tidak mencantumkan berapa lama gangguan berlangsung. Dalam pekerjaan maintenance rutin, sebuah perintah yang dijalankan untuk memeriksa kapasitas backbone global secara tidak sengaja memutus semua koneksi backbone, dan tools audit yang seharusnya memblokir perintah semacam itu gagal mencegahnya karena bug. Server DNS di lokasi kecil dirancang untuk menganggap dirinya tidak sehat dan menarik pengumuman rute BGP jika tidak bisa berkomunikasi dengan data center, sehingga server DNS tidak bisa dijangkau dari internet padahal masih berjalan. Jalur akses biasa dan akses out-of-band sama-sama terputus, dan tools internal juga kehilangan DNS, sehingga engineer harus dikirim langsung ke data center, dan prosedur keamanan membuat prosesnya makin lama. Saat pemulihan, konsumsi daya di setiap data center sudah turun puluhan MW, dan mengembalikan semuanya sekaligus dinilai berisiko bagi banyak hal, dari instalasi listrik sampai cache. Karena itu beban dinaikkan secara bertahap.
Jika gejala tidak bisa masuk / loading tanpa henti muncul serentak di semua wilayah dan semua ISP, periksa DNS dan rute BGP sebelum memeriksa server game. Hal ini bisa dipastikan juga dari luar perusahaan, lewat lookup DNS eksternal dan informasi rute BGP yang terbuka untuk publik. Penanggung jawab utama adalah Tim Infrastruktur (jaringan). Periksa lebih dulu bahwa jalur akses out-of-band dan tools internal yang dipakai saat gangguan tidak bergantung pada DNS dan jaringan yang sama, dan saat pemulihan, naikkan beban secara bertahap agar reconnect tidak datang sekaligus. Sumber asli
Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 7 Desember 2021 pukul 07.30 PST, jaringan internal region Virginia Utara (us-east-1) mengalami kongesti. Mulai pukul 07.33, error dan latensi API EC2 meningkat sehingga instance baru sulit dijalankan (peluncuran instance pulih pukul 14.40), lalu menyusul kegagalan login konsol, perubahan konfigurasi Route 53 yang tidak bisa dilakukan, serta metrik CloudWatch yang terlambat dan sebagian hilang. Perangkat jaringan pulih sepenuhnya pukul 14.22. Instance EC2 yang sudah berjalan dan respons DNS yang sudah ada tidak terdampak. Proses otomatis untuk menambah kapasitas sebuah layanan di jaringan utama memicu perilaku tak terduga dari banyak sekali klien di jaringan internal, sehingga upaya koneksi melonjak. Perangkat yang menghubungkan jaringan internal dan jaringan utama meluap sehingga komunikasi melambat, dan keterlambatan itu kembali menambah upaya koneksi dan retry, sehingga kongesti terus berlanjut. Klien sebenarnya punya mekanisme backoff yang memperpanjang jarak waktu di antara request saat kongesti seperti ini, tetapi mekanisme itu tidak bekerja dengan benar karena cacat tersembunyi. Monitoring internal juga bergantung pada jaringan yang sama, sehingga tim operasional menangani gangguan tanpa metrik real-time dan hanya mengandalkan log.
Jika retry tidak bisa memperpanjang jedanya, kongesti singkat bisa menjadi gangguan berjam-jam. Dari sisi game, server game yang sudah berjalan mungkin baik-baik saja, tetapi penambahan server baru (autoscaling), login, matchmaking, dan pembayaran yang memakai API cloud, serta monitoring bisa ikut terblokir. Sinyal yang perlu diperiksa adalah halaman status penyedia cloud, tingkat error API cloud, dan kegagalan peluncuran instance. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud). Tim Pengembang Game memasang exponential backoff dengan jeda acak dan batas jumlah percobaan pada semua retry, sedangkan Tim Infrastruktur menyiapkan kapasitas cadangan agar tetap bertahan saat penambahan server terblokir, serta alternatif di region lain. Sumber asli
Gangguan pada resolver DNS publik yang diatur sendiri oleh pemain di perangkat atau router. Pada jenis gangguan ini, semua game dan layanan ikut terblokir, tetapi hanya bagi pemain yang memakai pengaturan itu. Pada 14 Juli 2025 pukul 21.52–22.54 (UTC), selama 62 menit, resolver 1.1.1.1 tidak merespons di seluruh dunia. Cloudflare menyatakan bahwa bagi banyak pengguna, ini praktis berarti tidak bisa memakai layanan internet apa pun. Query UDP, TCP, dan DNS over TLS terdampak, sedangkan DNS over HTTPS, yang tersambung lewat nama domain, relatif stabil. Pada 6 Juni, saat menyiapkan topologi layanan (konfigurasi yang menentukan lokasi mana yang mengumumkan rentang IP tertentu) untuk layanan lain yang akan dipakai nanti, rentang IP resolver 1.1.1.1 tidak sengaja ikut dimasukkan ke konfigurasi itu. Pada 14 Juli, saat konfigurasi layanan tersebut diubah, lokasi yang mengumumkan rentang resolver menyusut dari semua lokasi menjadi satu lokasi yang sedang offline, dan rute BGP-nya ditarik di seluruh dunia. Perubahan ini langsung menyebar ke semua data center tanpa melalui canary deployment. Setelah konfigurasi dikembalikan pada pukul 22.20, trafik kembali hingga sekitar 77%, tetapi selama itu konfigurasi IP yang diperlukan sudah terhapus dari sekitar 23% server edge. Konfigurasi ulangnya membuat layanan baru normal pada pukul 22.54. Cloudflare menyatakan ini kesalahan konfigurasi internal yang tidak berkaitan dengan serangan atau pembajakan BGP (BGP hijacking).
Jika server game dan pemain lain normal, tetapi hanya sebagian pemain yang mengalami tidak bisa masuk / loading tanpa henti ke server login atau server patch, curigai DNS yang dipakai pemain tersebut. Cirinya, sesi yang sudah tersambung tetap bertahan dan hanya koneksi baru yang gagal. Penyebabnya langsung terpilah jika pemain diminta mengganti pengaturan DNS atau melakukan lookup alamat server secara langsung. Penanggung jawab utama adalah Pihak Eksternal (operator DNS, ISP). Jika Tim Pengembang Game (klien) membedakan kegagalan resolusi nama dari error lain dalam pesan ke pemain, tim CS bisa langsung menentukan penyebabnya. Sumber asli
Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Dari 19 Oktober 2025 pukul 23.48 sampai 20 Oktober pukul 14.20 (PDT), region Virginia Utara terdampak dalam tiga tahap. Error API DynamoDB meningkat sampai pukul 02.40 tanggal 20; peluncuran instance EC2 baru gagal dari pukul 02.25 sampai 10.36 (masalah koneksi pada sebagian instance baru teratasi pukul 13.50); dan error koneksi di sebagian Network Load Balancer (NLB) meningkat dari pukul 05.30 sampai 14.09. Otomatisasi yang mengelola DNS DynamoDB mengandung race condition tersembunyi. Di antara eksekutor yang menerapkan rencana DNS di availability zone yang berbeda (DNS Enactor), satu eksekutor yang tertunda sangat lama menimpa rencana baru dengan rencana lama. Tepat setelah itu, proses pembersihan dari eksekutor lain menghapus rencana lama tersebut, sehingga record DNS untuk endpoint region (dynamodb.us-east-1.amazonaws.com) menjadi kosong. Otomatisasi tidak bisa memperbaikinya, sehingga pemulihan harus dilakukan manual. Sistem pengelola server fisik EC2 bergantung pada DynamoDB, sehingga selama itu lease yang dipegang untuk setiap server fisik kedaluwarsa. Setelah DynamoDB pulih, jumlah server fisik terlalu banyak sehingga proses membuat ulang lease mengalami timeout sebelum selesai, dan pekerjaan retry kembali menumpuk hingga sistem masuk ke kondisi “congestive collapse” (runtuh akibat kongesti). Konfigurasi jaringan untuk instance yang baru dijalankan menyebar dengan lambat, sehingga health check NLB bolak-balik antara berhasil dan gagal, dan node yang sehat pun berulang kali keluar dari DNS lalu masuk kembali.
Kesalahan record DNS di satu tempat menjalar ke layanan lain yang bergantung pada layanan itu, dan setelah penyebabnya teratasi pun, pemulihan masih butuh beberapa jam lagi karena pekerjaan yang tertunda dan health check yang tidak stabil. Dari sisi game, server yang sudah berjalan mungkin bertahan, tetapi server baru tidak bisa dijalankan sehingga autoscaling berhenti, dan health check yang tidak stabil bisa membuat load balancer mengeluarkan server yang sebenarnya normal. Sinyal yang perlu diperiksa adalah halaman status cloud, tingkat error API layanan terkelola (managed service), kegagalan peluncuran instance, dan jumlah target sehat di load balancer. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud), sedangkan Tim Infrastruktur membatasi jumlah server yang boleh keluar sekaligus karena gagal health check dan menyiapkan alternatif di region lain. Sumber asli
Bagi Tim Pengembang Game dan Tim Infrastruktur, bagian yang paling lama dalam mencari penyebab adalah mengetahui “kapan, di mana, dan siapa”. Jika item-item berikut diisi, momen itu bisa langsung ditemukan di log dan grafik.
Istilah yang sering muncul saat berdiskusi dengan Tim Pengembang Game dan Tim Infrastruktur. Coba ketik dalam bahasa Indonesia atau Inggris di kolom pencarian.
Inilah dasar untuk angka, nilai default, dan penjelasan perilaku sistem di buku putih ini. Hanya sumber tepercaya yang dikumpulkan: dokumen standar (RFC), dokumentasi kernel dan OS, dokumentasi resmi cloud, engine, dan DB, serta presentasi dan makalah ilmiah. “Sumber” di kartu penyebab dan di akhir setiap bab juga mengarah ke referensi yang sama. Nilai default bisa berubah antarversi, jadi periksa dokumentasi versi yang Anda pakai sebelum menerapkannya.
616 referensi dari 83 penerbit. Daftarnya ada di daftar pustaka versi teks.