FiveM sunucusunda çalışan her script bir kaynak olarak paketlenir ve her kaynağın bedeli iki ayrı bütçeden ödenir. Biri sunucunun kendi işlem döngüsü, diğeri oyuncunun bilgisayarında geçen kare süresidir. Aynı script bu iki bütçeden çok farklı miktarlarda tüketebilir. Sunucuda neredeyse hiç yer kaplamayan bir kaynak oyuncunun ekranını takabilir, sunucuyu bekleten bir kaynak ise oyuncu tarafında hiçbir iz bırakmayabilir. Performans sorununun ilk sorusu bu yüzden hangi script’in kötü olduğu değil, hangi bütçenin dolduğudur.
Yük iki ayrı bütçeden çıkar
Sunucu tarafında FiveM tek bir ana döngü üzerinden ilerler. Sunucu her turda çalışması gereken kodu sırayla işler, bir kaynak bu turu uzun süre meşgul ederse geri kalan her şey sırasını bekler. Oyuncu bunu ışınlanan araçlar, geç açılan menüler ve komutlara gecikmeli tepki olarak görür. Sunucu konsolunda ise turun beklenenden uzun sürdüğünü bildiren takılma uyarısı, yani hitch warning satırı belirir.
İstemci tarafında aynı mantık kare süresi için işler. Her karede çalışan bir döngü o karenin bütçesinden pay alır, pay büyüdükçe kare hızı düşer. Bu düşüş yalnızca o oyuncunun bilgisayarında görünür ve sunucu bundan haberdar olmaz. İki oyuncunun aynı sunucuda tamamen farklı deneyim yaşamasının nedeni çoğu zaman budur.
Üçüncü bir kalem daha vardır: sunucudan indirilen varlıklar. Özel araçlar, kıyafetler ve harita dosyaları, yani streaming varlıkları, sunucu işlemcisini pek yormaz ama oyuncunun belleğini ve sunucuya ilk giriş süresini büyütür. Bu üç kalem birbirine karıştığında yapılan düzeltme genellikle yanlış yere uygulanır.
Ölçüm hangi ekrandan okunur
İstemci tarafındaki ölçüm oyunun içinden yapılır. F8 konsolundan açılan kaynak izleyici, kısa adıyla resmon, o an çalışan kaynakları tek tek listeler ve her birinin işlemci süresini milisaniye cinsinden, bellek kullanımıyla birlikte gösterir. Liste anlık olduğu için oyuncunun nerede durduğuna, açık menüye ve o sırada süren işe göre değişir.
Sunucu tarafında ilk ölçüm aracı konsolun kendisidir. Takılma uyarıları sunucunun hangi anlarda geciktiğini söyler, ama nedenini söylemez. Nedeni daraltmak için FiveM’in dahili profiler’i kullanılır: belirli sayıda kareyi kaydeder, kaydı dosyaya yazar ve hangi işlevin ne kadar sürdüğünü çıkarır. Kayıt, sorunun yaşandığı an alınmadığında işe yaramaz.
Ölçümün karşılaştırılabilir olması için testin canlı ortamda tekrarlanması gerekir. Oyuncuların bağlandığı bir fivem server üzerinde alınan kayıt ağ gecikmesini ve eşzamanlı oyuncu yükünü de içerir, kendi bilgisayarında tek başına yapılan denemede bu iki etkenin ikisi de yoktur. Saganetwork’ün oyun yönetim panelindeki kaynak izleme ekranı da dışarıdan bakan ikinci bir katman sağlar: panelden okunan işlemci ve bellek değeri hangi kaynağın sorumlu olduğunu söylemez, ancak sorunun sunucu tarafında olup olmadığını hızla ayırır.
Sayılar neyi söyler, neyi söylemez
Kaynak izleyicideki değer bir fotoğraftır, karakter değil. Aynı kaynak boştayken ve iş yaparken farklı maliyet üretir. Envanter kapalıyken sıfıra yakın duran bir script, envanter açıldığında listenin başına çıkabilir. Bu yüzden ölçüm en az iki koşulda alınır: sunucu sakinken ve kalabalıkken.
Bellek sütununda büyük bir sayı görmek tek başına arıza anlamına gelmez. Asıl gösterge sayının zaman içindeki davranışıdır. Sabit kalan yüksek bellek bir tasarım tercihidir, oturum boyunca durmadan büyüyen bellek ise sızıntıya işaret eder ve sunucu yeniden başlatılana kadar geri gelmez.
Kaynak sayısı da tek başına ölçüt değildir. Otuz küçük kaynak, kötü yazılmış tek bir kaynaktan daha az yük üretebilir. “Kaynak sayısını azalt” tavsiyesi bu nedenle çoğu kurulumda yanlış hedefi işaret eder. Ölçülen şey adet değil, o kaynağın turdan aldığı süredir.
Belirtiden yola çıkıp hangi bütçenin zorlandığını daraltmak ölçüm süresini kısaltır.
| Belirti | Zorlanan bütçe | Bakılacak yer |
| Bağlı olan herkes aynı anda takılıyor | Sunucunun ana döngüsü | Konsoldaki takılma uyarıları ve o an alınan profiler kaydı |
| Tek oyuncuda kare hızı düşük, diğerlerinde normal | İstemcinin kare süresi | O oyuncunun F8 konsolundaki kaynak izleyici listesi |
| Kalabalık bölgeye girerken donma, sonra düzelme | İstemci belleği ve varlık yükleme | Kaynak izleyicideki bellek sütunu ve streaming klasörü |
| Sunucuya ilk giriş çok uzun sürüyor | İndirme ve önbellek | Sunucudaki varlık dosyalarının toplam boyutu ve ağ tarafı |
| Belirli bir komutta anlık kilitlenme | Sunucu tarafında tek bir işlev | Komut çalıştırılırken alınan profiler kaydı |
Yükü büyüten tipik script davranışları
Ölçüm bir kaynağı işaret ettiğinde, sorunun kaynak içindeki karşılığı genellikle birkaç tanıdık desenden biri olur.
- Beklemesiz döngü: her karede dönen ama çoğu karede yapacak işi olmayan sonsuz döngü, boşta bile bütçeden pay alır.
- Sürekli mesafe hesabı: oyuncu ilgili bölgeden çok uzaktayken bile her karede yeniden hesaplanan uzaklık kontrolleri.
- Olay yağmuru: istemciden sunucuya sık aralıklarla gönderilen ve sunucuda tek tek doğrulanan olaylar, hem işlem hem ağ tarafında birikir.
- Döngü içinde veritabanı sorgusu: tek bir işlem için arka arkaya sorgu açan kaynak, sunucu turunu sorgu süresi kadar bekletir.
- İşlevi çakışan kaynaklar: envanter, bildirim veya araç kilidi gibi işleri iki ayrı kaynağın birlikte yapması, yükü çoğaltırken hata ayıklamayı da zorlaştırır.
- Sıkıştırılmamış varlık paketleri: yüksek çözünürlüklü araç ve harita dosyaları sunucu işlemcisini değil, oyuncunun belleğini ve ilk indirme süresini büyütür.
Sorumluyu daraltmanın sırası
Sıra burada yöntemin kendisidir, çünkü aynı anda yapılan iki değişiklik ölçümü okunamaz hale getirir.
- Belirtiyi tarif et: herkeste mi tek kişide mi, sürekli mi yoksa belirli bir eylemde mi.
- Sunucu sakinken ve kalabalıkken ayrı ölçüm al, iki kaydı yan yana koy.
- Şüpheli kaynağı geçici olarak durdur, aynı koşulu tekrarla ve farkı not et.
- Fark belirsiz kalıyorsa kaynağı tek başına, diğerleri kapalıyken çalıştır.
- Düzeltmeyi tek tek uygula, üç değişiklik aynı anda yapıldığında hangisinin işe yaradığı bilinmez.
- Değişiklikten sonra ölçümü aynı koşulda yeniden al ve önceki kayıtla karşılaştır.
Bu döngüde kaynak dosyalarının değiştirilmesi gerektiğinde panelin tam erişim FTP tarafı kullanılır. Düzenlemeye başlamadan önce ilgili kaynağın kopyasını almak, işe yaramayan bir değişikliği geri almanın en kısa yoludur.
Script tarafı bittiğinde donanım ne değiştirir
Donanım yükseltmesi kötü yazılmış bir döngüyü düzeltmez. Sunucu tarafındaki ana döngü sırayla ilerlediği için, tek bir kaynağın uzun süren işi çekirdek eklenerek ikiye bölünmez. Donanımın değiştirdiği şey iyi yazılmış bir kurulumun tavanıdır: aynı iş daha kısa sürede biter, bellek sınırına yaklaşınca başlayan yavaşlama gecikir, kayıt ve veritabanı işlemleri diskte daha az bekler.
Bu nedenle kaynak planı ile donanım planı ayrı ayrı kurulur. Saganetwork tarafında FiveM sunucu kiralama ile sanal sunucu paketleri farklı sorumluluk dağılımı sunar, Performans VDS tarafı yeni nesil işlemci ve NVMe SSD ile tanımlanır, ağ portu 1 Gbps olarak belirtilir ve varlık indirme süresi bu tarafta rol oynar. Sunucular Vodafone Veri Merkezi’nin kurumsal altyapısında barındırılmaktadır.
Aynı ölçüm iki sunucuda aynı kararı üretmez
Kabul edilebilir yük projeye göre değişir. Otuz kişilik bir roleplay kurulumunda göz ardı edilen bir gecikme, kalabalık bir sunucuda ilk düzeltilecek satır olur. Senaryosu ağır bir sunucuda normal sayılan bellek kullanımı, hafif bir yarış sunucusunda fazladan yük demektir. Dışarıdan taşınan tek bir doğru sayı yoktur, taşınabilir olan yöntemdir: belirtiyi tarif et, hangi bütçenin dolduğunu bul, tek değişken değiştir, ölçümü aynı koşulda tekrarla.
