LUTFEN BAŞTAN SONA OKUYUNUZ.

BILGI; LAG NEDIR ? PACKET LAR NEDIR ? LAG NASIL OLUŞUR ? BAĞLANTININ ÖNEMİ ? İŞLEMCİ HIZININ MAKİNENİZİN ÖNEMİ ? SPHERE İŞ BÖLÜMLERİ ? SCRIPTLERIN ETKISI ? NELER YAPILABILIR ?. Bu dokumanda tüm bu soruların cevabını alacaksınız. İyi okumalar potti ...

GENEL BILGI

Uzun yıllardır insanlar sphere serverların fazla playerlarda sürekli lag sorunu yaşadığını söylüyorlar. Bazı söylentilere göre bunun tamamen Sphere da olan bir hata ile ilgili olduğu söyleniyor. Bunlara rağmen bazı lag-free shardlardada oynadıklarını biliyorlar. Unutmamak gerekir ki bu serverlarda Sphere kullanıyor.

Yani, Sphere kullanan insanların sorduğu soru şu: Serverımı nasıl hızlandırabilirim ?

PACKET LAR

Uo da herşey "packet" formu halindedir. Bu packetlere " data tomarı " da diyebiliriz. 1 Saniye içinde aldığınız "packet" sayısı ne kadar lag a sahip olacağınızı belirleyen faktördür. Örnek: bir objeyi ( yerde bulunan ) belirleyen "packet" clientinize yolladığında 15 - 21 byte arası yer. Evet doğru okudunuz. Bu demek oluyorki etrafınızda bulunan ortalama 100 objenin açıklanması için karakteriniz sadece 1500 - 2100 byte alır. Bir kere clientiniz objeyi tanımladığında bunu "cache" olarak depolar ve tekrar almasına gerek kalmaz.

Önemli: Sphere, cliente small radarınızın gösterdiği alandaki bütün veriyi yollar. Buda neden Multi lerin siz görmeden radarınızda göründüğünü açıklıyor.


LAG NASIL OLUŞUR / BAĞLANTININ ÖNEMİ

Görüntü alanınızda bulunan objeler hakkında gerektiği hızda yenileme alamazsanız lag oluşur. Yani karakteriniz takılır ve etrafdaki bilgiyi almak için bekler. Bu tabiki sadece sizin clientinizin hızlı bilgi alamadığı için olmayabilir. Aynı zamanda Sphere Serverında bir bilgi gönderme noktası vardır ( end point ) bu nokta aşıldığında sphere server yüzünden lagda kalabilirsiniz. Örnek: Britain Bank civarında 100 item ve 50 player var. Bulunduğunuz server aynı anda 50 kişiye 2100 byte yollamaya çalışacaktır yani toplamda 105.000 byte yollayacaktır. Eğer serverınızın bulunduğu bağlantı 105 KB / s dan yüksekse herhangi bir lag hissedilmeyecektir.

Şimdi 50 player ve 100 item Britain bank için normaldir diyebilirsiniz fakat bunu sadece örnek olarak verdim. 105KB/s makul bir veri transfer hızıdır. Fakat şunu unutmayınki burdaki veri 1 saniye içinde olan ve sadece Britain Bank çevresindeki transferi gösteren bir veridir.

Önerim (Ingame ): Sık kullanılan alanlara, onlarca yüzlerce floor, wall part gibi itemler eklemeyin örneğin bir pvp alanı yapacaksanız yapın daha sonra staticlere bunu kaydedin. Böylece static dosyası playerın bilgisyarında olacağında sphere server bu gibi bölgelerde packet yollamayacaktır. ( Potti )
Önerim ( Hosting ): Host alırken dikkatli araştırın, VPS serverlardan kaçının. Bu tip serverlarda bağlantı sunucuyu kullanan kullanıcılar arasında paylaştırılır. 50 75 100 ytl ye kiralanan sunuculardan kaçının bu sunucular hiçbir zaman bu fiyatlarla isteklerinizi karşılayacak sunucular değildir. ( Potti )

LAG NASIL OLUŞUR / İŞLEMCİ HIZININ ÖNEMİ

Konumuza dönelim, bağlantı hız lag problemleri için birincil neden değildir. Evet static olmayan dekorasyonlar lag yapar fakat bundan başka nedenlerde vardır. Playerlara packet yollama dışında sphere serverın üstüne düşen görevleri vardır. Mesela world üstündeki tüm npc ve objeleri her saniye kontrol eder. Örnek: Kafasına göre dolaşan npc yürürken ağaçlara girmemelidir. Yer şekillerine göre hareketini belirlemelidir. Savaşan npc özelliklerine göre savaşmalıdır. @timer def ine sahip bir item sürekli yürütülmelidir. Playerların üzerindeki diğer scriptler yürütülmelidir.

Fakat, Sphere tüm iş parçalarını bu kadar güzel yürütebilen bir mekanizma değildir. Bu iş parçaları sphereın belirli bir zaman içinde birden çok şey yapmasını ister. Bu iş, genellikle "serverı yürütme işleri" dir, veya sphere serverın içinde bulunan bağımsız bir script olabilir. Genelde bağımsızdırlar fakat birbiriyle bağlantılı olanlarıda vardır. ( örn: save alma iş bölümü, scriptleri kontrol etme iş bölümü, vs / Potti ). Sonuçta hepsi aynı büyük bir uygulamanın parçasıdır. ( Burada aslında program denirken, sphereweb yada account sistemleri yada website istatistikleri gibi sphereserv.exe yle ortak çalışılan uygulamalardan da bahsedilmiştir ayrıca scriptlerin birbirleriyle bağıntılarına değinilmiştir. / Potti ) Eğer çoklu işlemiye sahipseniz, bilgisayarınız tüm iş bölümlerini ayrı işlemci üzerinde aynı anda kolayca çalıştırabilir. Aksi takdirde düşük bir işlemci boğulur.

Program giriş çıkışları arasında işler yürütülürken, programlar bilgisayarın cevap vermesi için bekler. Bu esnada programlar bilgisayardan data okumayı denerse, datanın tamamen hafızaya iletilmesini beklenmelidir. ( bu işlemler sırasında yavaş bir bilgisayar tepki "respond" vermeyebilir. ) Data tamamen hafızaya aktarılmadan hiç bir işlem yürümez. Fakat artık Windows I/O teknolojisi sayesinde data sorulurken diğer işlemlerin yürümesine olanak sağlamaktadır.

Önerim ( Bilgisayar ): Co-Located sunucu barındırma veya Dedicated server almayı düşünüyorsanız bunu iyi seçmeniz lazımdır. Cpu hızı, Ram bellek miktarı ve Harddisk kapasitesi bilgisayarınızın işlem hızını doğrudan etkileyen en önemli 3 faktördür. Burada tekrar, makine alırken VPS server alıyorsanız size ayrılan kısmı almadan önce sorunuz. Celeron işlemcili makinelere rağbet göstermeyiniz. ( Potti )

SPHERE İŞ PARÇACIKLARI

Sphere bazı iş parçaları kullanır. Farkettiyseniz sphere kapanırken " closing background threads " - " iş parçaları kapanıyor " diye bir uyarı alırsınız. Serverınız çalışırken sürekli scriptlerin değişiklik tarihlerinin izini sürer. Bu iş parçacıklarından biridir yani scriptleri kontrol etme fakat bu işlem düşük öncelikli bir iş parçacığıdır (Resync ). Bir diğer iş parçacığı save alınma sürecidir. Save esnasında save iş parçacığı arkaplandan ön plana gelir clientlere data aktarımı kesilir çünkü data yollayan Ana iş bölümü save işiyle uğraşmaktadır. Bu bize anlattığımız olayda çok önemli bir noktayı gösteriyor aslında. Sphere görevlerini yapmak için sadece "bir ana iş bölümüne" sahiptir. Buda demek oluyorki bir iş yer alırken diğer herşey durur. Sphere bir döngüdür. Aşağıda bir sphere ın çalışmasıyla ilgili bir örnek ve bu döngünün nasıl olduğunu göreceksiniz.

Server çalışırken, Sphere aşağıda döngüyü sürekli yapar.

- Bir iteme veya charachtere "çift tık" ladınız. Tıkladığınız şeye otomatik olarak -TIMERD fonksiyonu verilir.
- TIMERD=0 olduğunda yaptığın işlemi (yürümek veya savaşmak, itemse ele almak) durdur. ( Yürüdün durdun, savaştın durdun, itemi eline aldın elinde kaldı )
- Tüm scriptlerden dataları al.
- Eğer scriptlerde yaptığın işlemle yada üzerine uyguludığın item veya karakterle ilgili bir bağlantı varsa gerekli uygulamaları uygula.
- Yapılan işlemler clientlere somut olarak yolla.

( Okurken bile 2 kere gözünü kırptınız, Sphere bunları 1 saniye içinde onlarca kez denetler =). )

SCRIPTLERIN ETKISI

Gördüğünüz gibi sphere bunları çok kısa bir sürede halleder. Bu tip şeyler serverı yavaşlatmaz, bu işleri yavaşlatcak durumlar kendi yazdığınız scriptlere bağlıdır. İçsel hareketleri çok hızlı bir şekilde halleder ve bizim bozmamız için bu genel hareketler sphereın içinde hard-coded ( ellenemez, düzenlenemez, silinemez, değiştirilemek ) olarak mevcuttur. Gördüğünüz gibi sphere içsel scriptleri laga sebep olmaz, lag a sebep olacak scriptlerin birincil nedeni kendi yazdığımız scriptlerdir. Sizin için supriz mi oldu ? Okumaya devam edin.

Scripti yürütmek için, Sphere ilk önce dosyadan bunu okuması gerekmektedir. Hard-disk ten dosyaları okumak gerçekten yavaş bir işlemdir. Serverınız açtığınızda veya Resync ladığınızda, Sphere tüm scriptlerdeki başlıkları tek tek açıklar örnek "[ ITEMDEF i_hebelepotti ] exists yani i_hebelepotti duruyo yerinde tamam sorun yok... " . Diğelimki item duruyo ama bir sorun var item de herhangi bir event silinmiş. Eventlerde iş böyle değildir herhangi bir event askıda kalabilir. Yani önemli olan scriptin başını bulmaktır.

Neyse, server diğelimki bir i_hebelepotti yi buldu hemen scriptleri okumaya devam eder. Scriptin devamında geçen tüm veriable ve defname leri hafızaya alır. Anlatılmak isteneni inceler karar verir. Mesela i_gold dediğinizde bunun 0EED ile aynı şey olduğunu hafızasından belirler.

Bunun gibi scriptsel işleri sphere çok hızlı yapar. Fakat sphere a yardımınız olsun istiyorsanız tabiki yapabileceğiniz şeyler vardır. Scriptin açıklanması çok uzun süre aldığı için daha erken açıklanması serverın daha hızlı hareket etmesi anlamına gelecektir. Scriptleri daha hızlı hale getirme işlemine "Optimizasyon" denir. Ama unutmayın ilk önce scriptinizin doğru çalıştığına emin olun daha sonra optimizasyona gidin. Yani işlevi hıza herzaman tercih edin.

Scriptlerinizin daha hızlı çalışması için yapabilceğiniz birçok şey vardır ben bir kaçından örnek vericem.

1. Çıkışları kontrol edin, dönebildiğiniz kadar çabuk dönün ( RETURN ). Bu bir functionın doğru durabilmesi için gerekli birşeydir.

[FUNCTION tarayinlan_beni]
if (<src.str><70)
// ara beni
// ara beni
// tara beni
endif
return 1

Sphere, bu scripti çalıştırdığınız STR niz 70 den küçük mü ? diye bakar. Eğer öyleyse IF bloğunun gövde kısmına bakar. Eğer değilse her ELSEIF, ELIF, ELSE, ENDEIF bulana kadar her satıra tek tek bakar. Bu zaman alır dediğim gibi. Yukardaki scriptimizde STR 70 den küçük değilse ENDIF bulana kadar tüm line lar kontrol edilecektir ve bu gereksiz sphere ın yorulmasına sebep olacaktır. Daha hızlı script şu şekilde olabilir.

[FUNCTION tarayinlan_beni]
if (<src.str>>=70)
return 1
endif
// ara beni
// ara beni
// tara beni
return 1

Böyle yaptığımızda scriptin gereksiz satırları tekrar tekrar okumasını engelleriz. Yani Str 70 yada 70 ten büyükse RETURN le hemen. Ha eğer küçükse sonra istediğini yapabilirsin hiç değilse % 50 hızlandırdık =) .


2. ALLCLIENTS olayını gerekirse hiç kullanmayın.

Scriptiniz için bir vazgeçilmez ise kullanın fakat tedbirli kullanın. Çünkü ALLCLIENTS kullanımı sadece size değil tüm playerlara yavaş çalışan bir scripti entegre ettirdiğini düşünün sonuç facia. Ama sadece bir text yollamak örneğin bizim çok kullandığımız .anons gibi bir scripti kullanmanın fazla bir yükü olmayacaktır.


3. Aşırı TEKRARLAMA lardan kaçının. ( açıklama yok 99z versiyonu ile alakalı , 55i de sorun yok )

4. SECTORSLEEP modülünü sphere.ini den açın.

Bunu X (dakika) olarak ayarlayın. Böyle ayarladığınızda harita bölümleri X dakika içinde uykuya yatacaktır. Yani bir player o bölüme girmeden ordaki tüm timerlar 0 olacak. Bir player o bölgeye girdiğinde bölgedeki herşey eski haline dönecek timerlar olduğu yerden devam edecektir.

Npc hareketleri timerlara bağlıdır, bu timerlar 0 olursa player gelene kadar o bölgede herşey durur sphere sürekli kontrol etmek zorunda kalmaz. Peki bunun bir yanetkisi varmıdır ? Evet vardır. Mesela spawn noktaları timerlara bağlıdır. Diğelimki dünyadaki yaratıkları yeni spawnladınız yada spawnlara yeni reset attınız bu durumda o bölgeye player girmeden orada hiç birşey spawn olmaz. Aslında bu bir avantaj olabilir fakat ben size spawnları ayarlarken SECTORSLEEP i kapamanızı yani 0 yapmanızı öneriyorum daha sonra açabilirsiniz.

Hadi diyelim bir script yaptınız ve o scriptin için @timer triggerına sahip bir item var be bu item sleeping sectorda bulunuyor. Burada bulunan item artık düzgün çalışmayabilir. Aslında bu birçok @timer trigger lı sistemede etki edebilir.

Şunu unutmamak lazımdır SECTORSLEEP bazı scriptlerin garip davranmasına yol açabilir fakat lagı gerçekten iyi bir şekilde azaltır.


5. Fazla TAG ve VAR kullanımını azaltın.

Bu değerler özel bir listede tutulur ( bağlantılı sphere listesi ). Sphere bir şeyi bulmak isterse bu listeyi baştan sona sürekli tarar. Tabiki TAG lar ve VAR lar yüzünden yaşayacağınız lag gerçekten çok azdır ve o kadar sorun edilmesi gereken bir şey değildir. Tabiki bir playera 350 tane tag vermeniz serverı biraz laga sokabilir (abaaart! ), fakat bu 350 tag için yazcağınız scirptler sizi çok daha fazla sıkıntıya sokacaktır =). Taglar ve Varların kullanımıyla işiniz bittiğinde sildirmeyi unutmayınız.

6. Gereksiz spawnlardan kaçının. Özellikle Britain gibi çok kullanılan yerlerde.

Player yokken uykuya dalan bölgeler olsada Britain de bulunan 7-8 bölge hiç bir zaman uykuya girmeyeceğini bilmeniz gereklidir. Bu demek oluyorki çok kullanılan yerlere yerleştirdiğiniz herhangi bir hayvan yada Npc veriminizi düşürecektir.

7. Script içinde Çarpma ve Bölme işlemlerini gerketiği kadar az kullanın.

Bu sphere ın çalışmasında sapmalara neden olabilir. Toplama çıkarma bu kadar sorun olmaz fakat çarpma ve bölme işlemlerine fazla yer vermeyin ( hesap makinesi değil bu oldu olcak calculus sınavlarına sphere le girelim ) . Serverınızda büyük bir tehlike yaratmaz fakat gerektiği kadar az kullanmanızı tavsiye ediyorum.


8. Hesaplanan değerleri RETURN ile kapayın ( açıklamıyorum 99z versiyonu için gerekli, 55i de çözüldü )

9. EVAL, HVAL kullanmayın

HVAL basit gereksiz bir fonskiyondur. EVAL ise ;

- string - tag -var ve bazı sayı açıklamalarında kullanılabilir.

10. Fazla yeni obje yaratımından kaçının.

100 item yaratma 2.8 saniye alır. 100 Npc yaratmak bundan biraz daha uzun sürer alır. Yani obje yaratma yavaş bir işlemdir. Bunun nedeninde Sphereın ilk olarak objeyi yaratması sonra özelliklerini TYPEDEF e göre doldurması sonra diğer özelliklerini @create eventine bakması ... gibi nedenler sayılabilir.

11. EQUIP, BOUNCE yerine CONT kullanın.

Equip ve bounce işlevini sphere a sancılı anlar yaşatabilir bunun yerine bunları aşağıdaki gibi kullanın.

[FUNCTION equip_sword]
// ele kılıç alınması
NEWITEM i_sword_viking
ACT.CONT <UID>

[FUNCTION bounce_sword]
// çantaya kılıç alınması
NEWITEM i_sword_viking
ACT.CONT <FINDLAYER.layer_backpack.UID>

Gördünüzmü ? Kolay ve hızlı. Unutmayın eğer sphere ın extra bir equip işlevi yapmasını istiyorsanız mesela " bunu elinize alamazsınız " hatası vermesi gibi EQUIP işlevini kullanmalısınız. Ayrıca @equip ve @itemequip eventlerini kullancaksınız yine equip işlevini kullanın.

Yukarda bahsettiklerimi toparlamak gerekirse, optimizasyon Sphere a iyi bir hız kazandır ( 10 binlerce 100 binlerce milisaniye ).


Dökümanım burda bitiyor bu 3-4 saatlik çalışmamın gerçekten yaptığıma değdine ve size yardımcı olacağını umuyorum. En azından doğru barındırma seçimi ve lag azaltılması için yapılması gereken herşeyi anlattığımı düşünüyorum. Yukarıda yazdığım döküman genel olarak https://www.cs.rit.edu adresinden ingilizce kaynağından çevrilmiş olup, konu üzerinde kendi eklemelerim ve yorumlarım bulunmaktadır. Bu konuda dökümana ekleyebileceğim ek bilgiler hakkında fikriniz varsa lütfen irtibata geçiniz. / Potti
12 Kasım 2007