- Katılım
- 3 Ocak 2025
- Mesajlar
- 678
- Elmaslar
- 356
- Puan
- 2.355
- Konum
- Amasya
- Minecraft
- Zyph0rr
Discord:
bosstrap
Selam millet. Discord'da, forumda, her yerde dönen o klasik tartışma: "Abi sunucunda kaç eklenti var? 60 mı? Ee lag ondandır." Ya da tam tersi: "Kardeşim ben 120 eklentiyle 20 TPS gidiyorum sayıyla alakası yok." İkisi de kısmen haklı, ikisi de eksik. Biraz açalım.
Önce şunu anlayalım: sunucu aslında ne yapıyor?
Minecraft sunucusu saniyede 20 kez "tick" atar. Yani her 50 milisaniyede bir; mobları hareket ettirir, redstone'u hesaplar, chunkları günceller, oyuncuların hareketini işler. Eklentilerin kodu da büyük ölçüde bu aynı 50 ms'nin içinde çalışır.
Yani elinde 50 milisaniyelik bir bütçe var. Bu bütçeyi aşarsan tick uzar, TPS düşer, oyuncular "abi lag var" yazmaya başlar. Olay bu kadar basit.
Şimdi asıl soru: bu bütçeyi tüketen şey eklenti sayısı mı, yoksa eklentilerin ne yaptığı mı?
Minecraft sunucusu saniyede 20 kez "tick" atar. Yani her 50 milisaniyede bir; mobları hareket ettirir, redstone'u hesaplar, chunkları günceller, oyuncuların hareketini işler. Eklentilerin kodu da büyük ölçüde bu aynı 50 ms'nin içinde çalışır.
Yani elinde 50 milisaniyelik bir bütçe var. Bu bütçeyi aşarsan tick uzar, TPS düşer, oyuncular "abi lag var" yazmaya başlar. Olay bu kadar basit.
Şimdi asıl soru: bu bütçeyi tüketen şey eklenti sayısı mı, yoksa eklentilerin ne yaptığı mı?
Sayı yanıltıcı, işte nedeni
Üç senaryo düşün:
A sunucusu: 100 eklenti var ama çoğu küçük şeyler. Bir tanesi sohbeti renklendiriyor, biri /spawn komutu veriyor, biri girişte mesaj atıyor. Bunların tick başına maliyeti neredeyse sıfır.
B sunucusu: 20 eklenti var ama içinde bir tanesi her PlayerMoveEvent'te veritabanına sorgu atıyor. Oyuncu hareket ettiği sürece, saniyede onlarca kez, ana thread'i kilitleyerek.
C sunucusu: 40 eklenti var, hepsi düzgün yazılmış, asenkron çalışıyor.
B sunucusu en az eklentiye sahip olmasına rağmen en kötü performansı veren sunucu olur. Çünkü mesele adet değil, tick başına harcanan CPU süresi.
Kötü yazılmış tek bir eklenti, 80 tane düzgün eklentiden daha fazla zarar verebilir. Bunu defalarca gördüm.
Üç senaryo düşün:
A sunucusu: 100 eklenti var ama çoğu küçük şeyler. Bir tanesi sohbeti renklendiriyor, biri /spawn komutu veriyor, biri girişte mesaj atıyor. Bunların tick başına maliyeti neredeyse sıfır.
B sunucusu: 20 eklenti var ama içinde bir tanesi her PlayerMoveEvent'te veritabanına sorgu atıyor. Oyuncu hareket ettiği sürece, saniyede onlarca kez, ana thread'i kilitleyerek.
C sunucusu: 40 eklenti var, hepsi düzgün yazılmış, asenkron çalışıyor.
B sunucusu en az eklentiye sahip olmasına rağmen en kötü performansı veren sunucu olur. Çünkü mesele adet değil, tick başına harcanan CPU süresi.
Kötü yazılmış tek bir eklenti, 80 tane düzgün eklentiden daha fazla zarar verebilir. Bunu defalarca gördüm.
Peki gerçekten neye mal oluyor?
Bir eklentinin pahalı olmasının tipik sebepleri:
Sık tetiklenen event'lere bağlanmak. PlayerMoveEvent, BlockPhysicsEvent, EntityDamageEvent... Bunlar saniyede yüzlerce kez tetiklenir. Buraya ağır kod koyarsan biter.
Ana thread'de disk/veritabanı işlemi. MySQL sorgusu senkron atılıyorsa, sunucu o sorgu bitene kadar durur. Ping kötüyse tick 200 ms'ye çıkar.
Her tick çalışan scheduler görevleri. Scoreboard'u her tick güncelleyen eklenti klasiktir.
Chunk yükleme. Uzaktaki bir bölgeyi zorla yükleten eklenti (bazı korumalar, bazı ekonomi/arazi eklentileri) ciddi maliyetlidir.
Üst üste binen eklentiler. 4 farklı eklenti aynı event'i dinliyorsa, aynı iş 4 kez yapılıyor demektir.
Buna karşılık; menü açan, komut veren, mesaj yazan eklentiler sadece kullanıldıkları anda çalışır. 50 tanesi yan yana dursa fark etmez.
Bir eklentinin pahalı olmasının tipik sebepleri:
Sık tetiklenen event'lere bağlanmak. PlayerMoveEvent, BlockPhysicsEvent, EntityDamageEvent... Bunlar saniyede yüzlerce kez tetiklenir. Buraya ağır kod koyarsan biter.
Ana thread'de disk/veritabanı işlemi. MySQL sorgusu senkron atılıyorsa, sunucu o sorgu bitene kadar durur. Ping kötüyse tick 200 ms'ye çıkar.
Her tick çalışan scheduler görevleri. Scoreboard'u her tick güncelleyen eklenti klasiktir.
Chunk yükleme. Uzaktaki bir bölgeyi zorla yükleten eklenti (bazı korumalar, bazı ekonomi/arazi eklentileri) ciddi maliyetlidir.
Üst üste binen eklentiler. 4 farklı eklenti aynı event'i dinliyorsa, aynı iş 4 kez yapılıyor demektir.
Buna karşılık; menü açan, komut veren, mesaj yazan eklentiler sadece kullanıldıkları anda çalışır. 50 tanesi yan yana dursa fark etmez.
Ama "sayının hiç önemi yok" demek de doğru değil
Şunlar var:
İstatistik meselesi. 100 eklenti kurduysan, içlerinde en az bir tane kötü yazılmış olanın çıkma ihtimali çok daha yüksek. Sayı arttıkça risk artıyor.
Çakışma ve debug cehennemi. 100 eklentiyle bir sorun çıktığında hangisinden kaynaklandığını bulmak işkenceye dönüyor. Teker teker kapatıp
test etmen gerekiyor.
RAM. Her eklenti kendi verisini, cache'ini, config'ini bellekte tutar. Tek başına küçük, ama 100 tanesi toplamda gigabaytlara varabilir. RAM dolunca da GC devreye girer, o da tick'leri tırmalar.
Açılış süresi. 100 eklentili sunucu 20 eklentili sunucudan çok daha yavaş açılır. Oyun içi performansı etkilemez ama restart yerken canını sıkar.
Güncelleme yükü. Sürüm atladığında 100 eklentiyi tek tek kontrol etmen lazım.
Yani sayı doğrudan bir performans metriği değil, ama dolaylı bir risk göstergesi.
Şunlar var:
İstatistik meselesi. 100 eklenti kurduysan, içlerinde en az bir tane kötü yazılmış olanın çıkma ihtimali çok daha yüksek. Sayı arttıkça risk artıyor.
Çakışma ve debug cehennemi. 100 eklentiyle bir sorun çıktığında hangisinden kaynaklandığını bulmak işkenceye dönüyor. Teker teker kapatıp
test etmen gerekiyor.
RAM. Her eklenti kendi verisini, cache'ini, config'ini bellekte tutar. Tek başına küçük, ama 100 tanesi toplamda gigabaytlara varabilir. RAM dolunca da GC devreye girer, o da tick'leri tırmalar.
Açılış süresi. 100 eklentili sunucu 20 eklentili sunucudan çok daha yavaş açılır. Oyun içi performansı etkilemez ama restart yerken canını sıkar.
Güncelleme yükü. Sürüm atladığında 100 eklentiyi tek tek kontrol etmen lazım.
Yani sayı doğrudan bir performans metriği değil, ama dolaylı bir risk göstergesi.
Tahmin etmeyi bırak, ölç
En sinir bozucu şey, insanların "bence şu eklenti yiyordur" diye tahmin yürütmesi. Ölçmek çok kolay:
En sinir bozucu şey, insanların "bence şu eklenti yiyordur" diye tahmin yürütmesi. Ölçmek çok kolay:
- Spark kur (/spark profiler start → biraz bekle → /spark profiler stop). Sana hangi eklentinin, hangi metodun ne kadar CPU yediğini satır satır çıkarır. Fark yaratan tek araç budur.
- /tps ve özellikle MSPT değerine bak. MSPT 50'nin altındaysa iyisin, 50'yi geçiyorsa TPS düşmeye başlar.
- Paper kullanıyorsan /spark health ile genel duruma bakabilirsin.
Spark raporunu okuduktan sonra tartışma bitiyor zaten, suçlu ortada oluyor.
Pratik tavsiyeler
- Kurduğun her eklentinin config'ini aç, kullanmadığın modülleri kapat. Özellikle çok işlevli "all-in-one" eklentilerde bu ciddi fark yaratır.
- Aynı işi yapan iki eklenti varsa birini sil. Üç tane koruma eklentisi gereksiz.
- Yeni eklenti kurarken tek tek kur ve MSPT'yi izle. 10 tanesini aynı anda atıp sonra "nerden çıktı bu lag" deme.
- Kaynağı belirsiz, forumdan indirilmiş, güncellenmemiş eklentilerden uzak dur. Performans bir yana, güvenlik riski de var.
- Bir de şunu unutmayın: lag'in kaynağı çoğu zaman eklenti bile olmuyor. Aşırı mob/item birikmesi, redstone makineleri, yüksek view-distance, sürekli yeni chunk üreten oyuncular, ya da düpedüz zayıf tek çekirdek performansı olan ucuz hosting... Eklentileri suçlamadan önce bunlara da bakın.
Özet
Eklenti sayısı tek başına bir şey ifade etmiyor. 100 düzgün eklenti gayet rahat çalışır, 20 kötü eklenti sunucunu dizlerinin üstüne çökertir. Ama sayı arttıkça kötü olanın bulaşma riski, çakışma ihtimali ve bakım yükü de artıyor, bu yüzden "az ve öz" yaklaşımı hâlâ mantıklı.
Kural şu: ihtiyacın olanı kur, config'ini düzgün ayarla, düzenli olarak spark ile ölç.
Eklenti sayısı tek başına bir şey ifade etmiyor. 100 düzgün eklenti gayet rahat çalışır, 20 kötü eklenti sunucunu dizlerinin üstüne çökertir. Ama sayı arttıkça kötü olanın bulaşma riski, çakışma ihtimali ve bakım yükü de artıyor, bu yüzden "az ve öz" yaklaşımı hâlâ mantıklı.
Kural şu: ihtiyacın olanı kur, config'ini düzgün ayarla, düzenli olarak spark ile ölç.