Anasayfa
UO Sunucular
Forumlar
Profilim
UO-Developer.COM

Ultima Online — SphereServer Lag ve Optimizasyon Rehberi

UO-Developer.com — paketler, CPU, script ve hosting optimizasyonu

Bu rehber, Sphere tabanlı Ultima Online shard'larında yaşanan lag sorunlarının nedenlerini açıklar ve pratik optimizasyon adımları sunar. Konu başlıkları: lag nedir, paketler, bağlantı ve CPU etkisi, iş parçacıkları, script optimizasyonu ve kontrol listesi.

İlgili site dokümanı: Lag Hakkında Herşey


İçindekiler
  • Genel bilgi
  • UO'da paketler (packets) nedir?
  • Lag nasıl oluşur?
  • Sphere iş parçacıkları (threads)
  • Sphere'in ana döngüsü
  • Scriptlerin lag'e etkisi ve optimizasyon
  • Özet kontrol listesi
  • Son söz

1. Genel Bilgi

Ultima Online topluluğunda yıllardır tartışılan en önemli konulardan biri, yüksek oyuncu sayılarında yaşanan lag sorunudur. Bir kesim bunun doğrudan SphereServer'ın kendisindeki bir hatadan kaynaklandığını öne sürerken, aynı Sphere motorunu kullanan bazı shard'ların lag-free çalıştığı da bilinmektedir.

O hâlde sorun çoğu zaman Sphere'in kendisinden değil, nasıl yapılandırıldığından ve nasıl kullanıldığından kaynaklanır. Bu rehber, shard yöneticilerinin lag sorununu anlamasına ve çözmesine yardımcı olmak amacıyla hazırlanmıştır.

Kurulum henüz tamamlanmadıysa önce: Sphere Server 56B Kurulum | Türkçe Sphere.ini


2. UO'da Paketler (Packets) Nedir?

Ultima Online istemcisi (client) ile sunucu (server) arasındaki tüm iletişim paket adı verilen küçük veri birimleriyle gerçekleşir. Her aksiyon, her nesne, her hareket bir paket üretir ve karşı tarafa iletilir.

2.1 — Paket boyutları (referans)
  • Yerde duran 1 adet item — 15 – 21 byte
  • 100 item (görüş alanında) — ~1.500 – 2.100 byte
  • 1 karakterin tam verisi — ~50 – 100 byte
  • Hareket paketi (tek adım) — 7 byte
  • Konuşma (speech) paketi — metne göre değişir
2.2 — Radar alanı (önemli ayrıntı)

Sphere, istemciye yalnızca ekranda görünen alandaki değil, mini haritanın (small radar) kapsadığı tüm alandaki nesne verilerini gönderir. Bu yüzden görüş alanınızın dışındaki Multi yapılar (evler, gemiler) radar üzerinde belirginleşebilir; sunucu o veriyi zaten göndermiştir. Bu tasarım oyun deneyimini iyileştirse de sunucu üzerindeki paket yükünü artırır.

2.3 — Cache mekanizması

İstemci bir nesneyi bir kez aldıktan sonra bunu önbelleğe (cache) alır; sunucunun o nesneyi tekrar göndermesine gerek kalmaz. Nesne üzerinde değişiklik olursa (item kaldırıldı, NPC öldü) sunucu güncelleme paketi yollar. Bu mekanizma bant genişliği kullanımını büyük ölçüde azaltır.


3. Lag Nasıl Oluşur?

Lag, istemcinin ihtiyaç duyduğu paketleri yeterli hızda alamaması ya da sunucunun paketleri yeterli hızda üretip gönderememesi sonucunda oluşur. İki temel kaynağı vardır:

3.1 — Bağlantı kaynaklı lag

Sunucunun bant genişliği aşıldığında paketler sıraya girer ve gecikmeli iletilir.

Örnek hesaplama:

  • Britain Bank bölgesinde 50 oyuncu ve 100 item olduğunu varsayalım
  • Her oyuncuya ~2.100 byte veri gönderimi gerekir
  • 50 oyuncu × 2.100 byte = 105.000 byte/sn (~105 KB/s) yalnızca bu bölge için
  • Sunucunuzun toplam çıkış bant genişliği bunun katı kadar trafik üretebilir (diğer bölgeler, yönetim trafiği, web sitesi vb.)
  • Bu değerin üstüne çıkıldığında lag başlar

Not: 105 KB/s düşük görünebilir; ancak bu rakam yalnızca tek bir bölgenin 1 saniyelik anlık yükünü temsil eder. Aktif bir shard'da onlarca bölge eş zamanlı trafik üretir.

Öneriler:

  • Sık kullanılan alanlara (Britain, Vesper, Yew bankaları gibi) yüzlerce yerleştirilmiş dinamik item eklemeyin. Dekorasyonu tasarladıktan sonra static dosyasına (statics.mul) kaydedin — static nesneler istemci dosyasında olduğundan sunucu bu nesneler için paket üretmez
  • Static yapım rehberleri: CentrED ile Static Yapımı | Axis ile Static Yapımı | Multool Kullanımı
  • Host seçiminde VPS kullanmaktan mümkün olduğunca kaçının — ağ bant genişliği diğer kiracılarla paylaşılır; anlık yoğunlukta daralma yaşanabilir. Dedicated veya Co-Located sunucu tercih edin
  • Barındırma şirketinden taahhüt edilen çıkış bant genişliğini ve port hızını (1 Gbit/s, 100 Mbit/s) net olarak sorun
3.2 — İşlemci (CPU) kaynaklı lag

Bağlantı hızı tek başına yeterli değildir. Sphere, ağ trafiği dışında her saniye onlarca hesaplama yapar:

  • Haritadaki tüm NPC'lerin yürüme, çarpışma ve pathfinding kontrolü
  • Aktif tüm @timer trigger'larının işlenmesi
  • Savaşan NPC'lerin yapay zeka hesaplamaları
  • Oyuncu üzerindeki script efektlerinin güncellenmesi
  • Spawn noktalarının düzenli kontrolü
  • Otomatik save işlemleri

Sphere'in en kritik mimarî sınırlaması: Tüm bu işler tek bir ana iş parçacığında (single main thread) sırayla yapılır. Bir işlem tamamlanmadan diğeri başlamaz. Düşük işlemci hızında sıra tıkanır ve lag oluşur.

Öneriler:

  • Sunucu için Dedicated veya Co-Located makine tercih edin
  • CPU seçiminde saat hızı (GHz) birincil kriterdir; Sphere çok çekirdekten yararlanamaz — yüksek single-core performansı önemlidir
  • Celeron serisi işlemcilerden kaçının (düşük clock + kısıtlı önbellek)
  • RAM: script tabloları, NPC ve oyuncu verileri bellekte tutulur — 2 GB ve üzeri önerilir

4. Sphere İş Parçacıkları (Threads)

Sphere kapanırken konsolda Closing background threads mesajını görürsünüz; arka planda çalışan yardımcı iş parçacıklarının sonlandırıldığını bildirir.

4.1 — Bilinen iş parçacıkları
  • Ana döngü (Main Loop) — Tüm oyun mantığı, NPC hareketleri ve script trigger'ları. Öncelik: en yüksek
  • Save — Dünya verisini diske yazar; aktif olduğunda ana döngü kısmen durur. Öncelik: yüksek (geçici)
  • Resync — Script dosyalarındaki değişiklikleri izler ve yeniden yükler. Öncelik: düşük
  • Network I/O — Oyunculara paket gönderip alır. Öncelik: yüksek
4.2 — Save sırasında neden lag olur?

Save işlemi başladığında Sphere, dünya verisini tutarlı hâlde diske yazabilmek için istemcilere paket gönderimini kısa süreliğine askıya alır. Bu sürede ekran donabilir veya karakter yerinde sayabilir.

Save süresini kısaltmak için:

  • Gereksiz item ve NPC sayısını düşürün
  • sphere.ini içinde save aralığını (SavePeriod) ihtiyacınıza göre ayarlayın; çok sık save ek yük yaratır
  • Yedekleme rehberi: Sphere — Server Backup

5. Sphere'in Ana Döngüsü

Sunucu çalışırken Sphere aşağıdaki döngüyü her saniye defalarca tekrarlar:

1. Tüm aktif timer'ları kontrol et → TIMERD değerlerini azalt
2. TIMERD = 0 olan nesneler için ilgili trigger'ı çalıştır (@timer, @step, vb.)
3. Oyunculardan gelen paketleri oku (hareket, tıklama, konuşma, vb.)
4. Her paketi ilgili script bloğuyla eşleştir ve işle
5. Sonuçları paket hâlinde tüm ilgili istemcilere gönder
6. Döngüye geri dön

Bu döngü ne kadar hızlı tamamlanırsa oyun o kadar akıcı çalışır. Döngüyü yavaşlatan her script satırı doğrudan lag'e dönüşür.

Script ekleme / reload: Script Nasıl Eklenir? | Script Ekleme


6. Scriptlerin Lag'e Etkisi ve Optimizasyon

Sphere'in dahili (hard-coded) mekanizmaları son derece hızlı çalışır; bunları optimize etmenize gerek yoktur. Lag'in asıl kaynağı shard yöneticilerinin yazdığı özel scriptlerdir.

Altın kural: Önce doğru çalışan bir script yazın, ardından optimize edin. İşlevselliği hız uğruna feda etmeyin.

Teknik 1 — Erken RETURN kullanımı

Sphere bir if bloğu içine girdiğinde, koşul sağlanmasa bile ENDIF satırına ulaşmak için her satırı okur. Koşul sağlandığında hemen RETURN ile çıkmak gereksiz okumayı önler; basit değişiklikle script ~%50 daha hızlı çalışabilir.

Yavaş versiyon:

[FUNCTION kontrol_et]
if (<STR> < 70)
  // islem yap
  // islem yap
  // islem yap
endif
return 1

Hızlı versiyon:

[FUNCTION kontrol_et]
if (<STR> >= 70)
  return 1
endif
// islem yap
// islem yap
// islem yap
return 1
Teknik 2 — ALLCLIENTS kullanımını sınırlayın

ALLCLIENTS komutu scripti sunucudaki tüm bağlı oyuncular için ayrı ayrı çalıştırır. 200 oyuncuda script 200 kez işlenir. Ağır scriptlerde sunucu kilitlenebilir.

  • .anons gibi yalnızca metin gönderen hafif scriptlerde kabul edilebilir
  • NPC hareketi, item yaratma veya karmaşık hesaplama içeren scriptlerde kesinlikle kullanmayın
  • Mümkünse belirli bölgeye veya belirli oyunculara yönelik alternatifler kullanın
Teknik 3 — SectorSleep etkinleştirin

sphere.ini dosyasında SectorSleep değerini açın:

SectorSleep=5   ; 5 dakika hareketsizlik sonrasi sektor uykuya gecer

Haritada hiçbir oyuncunun bulunmadığı sektörler belirli süre sonra uyku moduna geçer. Uykudaki sektörlerdeki timer'lar 0'a çekilir; NPC'ler hareket etmez, script trigger'ları çalışmaz. Oyuncu sektöre girdiğinde devam eder.

  • Avantaj: Kullanılmayan sektörlerde gereksiz hesaplama yapılmaz
  • Dikkat: @timer trigger'lı itemler uyuyan sektörde beklenmedik davranış gösterebilir
  • Spawn noktaları timer'a bağlıdır; spawn ayarı yaparken SectorSleep=0 yapıp ayar bitince tekrar açın

Tüm ini parametreleri: Türkçe Sphere.ini

Teknik 4 — TAG ve VAR kullanımını minimize edin

Tag'ler ve VAR'lar bağlantılı liste (linked list) yapısında tutulur. Sphere bir tag aramak için listeyi baştan sona tarar. Onlarca tag birikince maliyet artar.

  • İşlevi biten tag'leri CTAG0 veya TAG0 ile silin
  • Geçici hesaplamalar için mümkünse script içi local değişken kullanın
  • Bir oyuncuya aşırı miktarda (50+) tag veren sistemleri yeniden tasarlayın
Teknik 5 — Yoğun bölgelerde gereksiz spawn kurmayın

Britain, Vesper, Trinsic gibi sürekli dolu bölgelerde SectorSleep devreye girmez; sektörler uykuya geçmez. Bu alanlardaki her NPC sürekli hesaplama yükü oluşturur.

  • Yoğun bölgelerdeki spawn sayısını minimumda tutun
  • Dekoratif NPC yerine static grafik kullanmayı değerlendirin
Teknik 6 — Sık item ve NPC yaratımından kaçının

NEWITEM ve NEWNPC maliyetli işlemlerdir: hafıza ayırma, tanım okuma, @CREATE trigger, dünya listesine kayıt.

Referans: 100 item yaratmak yaklaşık 2,8 saniye alır. Döngü içinde yapılırsa sunucu bu süre boyunca diğer işlemleri yürütemez.

  • Mümkünse nesneleri önceden yerleştirin; dinamik yaratımı minimize edin
  • Toplu yaratım gerekiyorsa @timer ile kademeli yaratım yapın
Teknik 7 — EQUIP / BOUNCE yerine CONT kullanın

EQUIP ve BOUNCE ekstra doğrulama adımları çalıştırır. Yalnızca envantere veya yere koymak için CONT daha performanslıdır:

[FUNCTION kilic_ver]
NEWITEM i_sword_viking
ACT.CONT         ; itemi dogrudan hedefe koy

EQUIP yalnızca @EQUIP / @ITEMEQUIP trigger'ına veya equip hata mekanizmasına ihtiyaç varsa kullanın.

Teknik 8 — Çarpma ve bölme işlemlerini sınırlayın

Sphere script motoru toplama/çıkarmaya kıyasla çarpma ve bölmeyi daha yavaş işler. Döngü içinde fark birikir.

  • Sabit sonuçlu çarpma/bölmeleri önceden hesaplayıp tag veya define olarak saklayın
  • Döngü içinde gereksiz matematiksel işlemden kaçının
Teknik 9 — EVAL ve HVAL kullanmayın
  • HVAL — Gereksiz ve eski; hiçbir yerde kullanılmamalı
  • EVAL — Yalnızca string-to-number gibi zorunlu durumlarda; hesaplamaları doğrudan Sphere aritmetik sözdizimi ile yapın

7. Özet Kontrol Listesi

Shard'ınızı optimize etmeden önce gözden geçirin:

  • [ ] Sık kullanılan alanlardaki dinamik itemler static'e dönüştürüldü mü?
  • [ ] Sunucu Dedicated / Co-Located mı? (VPS'ten kaçınıldı mı?)
  • [ ] CPU single-core hızı yeterli mi? (Celeron kullanılmıyor mu?)
  • [ ] SectorSleep etkinleştirildi mi?
  • [ ] @timer trigger'ları RETURN ile erken çıkış yapıyor mu?
  • [ ] ALLCLIENTS kullanımı minimuma indirildi mi?
  • [ ] Gereksiz TAG ve VAR'lar işlem bitince siliniyor mu?
  • [ ] Yoğun bölgelerde spawn sayısı makul seviyede mi?
  • [ ] Büyük döngülerde NEWITEM / NEWNPC kullanımından kaçınıldı mı?
  • [ ] HVAL ve gereksiz EVAL kullanımı temizlendi mi?

8. Son Söz

Lag, büyük çoğunlukla yanlış yapılandırılmış sunucu, yetersiz hosting veya optimize edilmemiş scriptlerin sonucudur. Sphere kendi iç mekanizmalarıyla son derece verimli çalışabilmektedir; asıl yükü shard yöneticilerinin eklediği içerik ve scriptler oluşturur.

Doğru sunucu seçimi, dikkatli script yazımı ve yukarıdaki optimizasyon tekniklerinin uygulanmasıyla yüzlerce oyuncuyu lag-free ağırlayan bir shard kurmak mümkündür.

İlgili rehberler:

UO-Developer.com — Sphere lag ve optimizasyon rehberi

UO-Dev SPONSOR

Paylaş

XFacebook

Faydalı mı?

Bu içerik size yardımcı oldu mu?

UO-Dev SPONSOR

Henüz yorum yapılmamış. Yorum yazabilmek için giriş yapmanız gerekir.

Üyelerin oylama ortalaması (10 dışında) :

8.50

Oylar: 2 den itibaren 28-08-2012 03:33

Paylaş

XFacebook

Faydalı mı?

Bu içerik size yardımcı oldu mu?