FurKqn
Medieval Fantasy
- Katılım
- 18 Temmuz 2016
- Mesajlar
- 304
- Elmaslar
- 116
- Puan
- 14.030
- Yaş
- 27
- Konum
- İstanbul
- Discord İzni
- Minecraft
- Furkqn
Discord:
furkqn
Herkese merhaba ben Furkan.
Bu rehber, Spark'ın resmi belgelerinden bir makalenin neredeyse birebir çevirisidir.
Bu rehberde eklentinin tüm işlevlerinden bahsedilmeyecektir. Sadece "spark rehberleri" bölümünden alınan bilgiler yer alacaktır.
Bu makalenin paylaşılmasındaki amaç, Spark'ı bilmeyen ve İngilizce konusunda çok bilgili olmayan kullanıcıların, bu aracı kullanmayı öğrenmelerine yardımcı olmak ve daha da önemlisi, nasıl doğru kullanılacağını anlamalarını sağlamaktır!
Bölüm 1 - Giriş. TPS, MSPT ve anlamları
(Eğer bu terimlere zaten aşina iseniz, doğrudan 2. bölüme geçebilirsiniz)
Neredeyse tüm video oyunları (Minecraft dahil) büyük bir ana program döngüsü ile yönetilir. Sunucu (ve oyun) işlemleri, "tick" adı verilen döngülere bölünmüştür.
Bu rehber, Spark'ın resmi belgelerinden bir makalenin neredeyse birebir çevirisidir.
Bu rehberde eklentinin tüm işlevlerinden bahsedilmeyecektir. Sadece "spark rehberleri" bölümünden alınan bilgiler yer alacaktır.
Bu makalenin paylaşılmasındaki amaç, Spark'ı bilmeyen ve İngilizce konusunda çok bilgili olmayan kullanıcıların, bu aracı kullanmayı öğrenmelerine yardımcı olmak ve daha da önemlisi, nasıl doğru kullanılacağını anlamalarını sağlamaktır!
Bölüm 1 - Giriş. TPS, MSPT ve anlamları
(Eğer bu terimlere zaten aşina iseniz, doğrudan 2. bölüme geçebilirsiniz)
Neredeyse tüm video oyunları (Minecraft dahil) büyük bir ana program döngüsü ile yönetilir. Sunucu (ve oyun) işlemleri, "tick" adı verilen döngülere bölünmüştür.
Her "tick" gerçekleştiğinde, oyun sunucusu şu işlemleri yapacaktır:
• Oyunculardan gelen paketleri işleme (örneğin; hareket, blok yerleştirme / yıkma, diğer nesnelere saldırma)
• Oyuncuların ve diğer varlıkların pozisyonlarını güncelleme
• Sunucuda gerçekleşen olaylar hakkında (blok değişiklikleri, nesne hareketleri ve eylemler) tüm oyunculara paketler gönderme
• Yeni yaratıklar oluşturma, yapay zekayı işleme, yol bulma vb.
• Redstone güncellemelerini işleme
Ve daha fazlası!
Minecraft sunucusu, her saniyede tam olarak 20 "tick" çalıştırmayı hedefler, yani her 50 milisaniyede bir tick gerçekleşir.
Tabii ki, her tick'in gerçekleştirilmesi için gereken iş miktarı oyunda neler olup bittiğine göre değişir. Bu yüzden tick'ler pratikte asla bu kadar düzenli olmaz!
Sunucu düzgün çalıştığında, bir tick'in tamamlanması için gereken sürenin 50 milisaniyeden az (ya da buna eşit) olması gerekir. Eğer bir tick 50 milisaniyeden daha kısa sürede işlenirse, sunucu bir sonraki tick’i başlatmaya hazır olana kadar kalan süre boyunca "uyur", yani işlem yapmaz.
Sunucu düzgün çalıştığında, bir tick'in tamamlanması için gereken sürenin 50 milisaniyeden az (ya da buna eşit) olması gerekir. Eğer bir tick 50 milisaniyeden daha kısa sürede işlenirse, sunucu bir sonraki tick’i başlatmaya hazır olana kadar kalan süre boyunca "uyur", yani işlem yapmaz.
Mesela:
- Sunucu bir tick’i tamamlamak için 15 milisaniye harcıyor.
- Tick döngüsü kontrolcüsü, bir sonraki tick’i başlatmadan önce 35 milisaniye boyunca "uyur" (hiçbir şey yapmaz).
Gördüğünüz gibi, bu örnekte tüm tick'ler 50 milisaniyeden daha kısa sürdü, ancak bunlar bir saniyede tam olarak 20 tick işlenecek şekilde dağıtıldı. Eğer sunucu tick'ler arasında boşluk bırakmasaydı (yani bu "uyku" modunu kullanmasaydı), oyun gerçekten "daha hızlı" hissedilirdi – her şey daha hızlı gerçekleşirdi! (canavarlar daha hızlı hareket ederdi, vb.)
Ancak, bir tick 50 milisaniyeden daha uzun sürerse, bir sonraki tick’in işlenmesi gecikmek zorunda kalır çünkü tick'ler aynı anda, paralel olarak işlenemez. Bu gerçekleştiğinde, oyun deneyimi kötüleşmeye başlar çünkü her şey daha az tepki verir hale gelir ve "lag" yani gecikme yaşanır.
Gördüğünüz gibi, tek tek tick'ler daha fazla zaman almaya başladığında, her şey "sağa kayar" ve aynı zaman diliminde daha az oyun tick'i gerçekleşir. İşte bu yüzden sunucu geciktiğinde, her şey daha yavaş işler.
Ancak, bir tick 50 milisaniyeden daha uzun sürerse, bir sonraki tick’in işlenmesi gecikmek zorunda kalır çünkü tick'ler aynı anda, paralel olarak işlenemez. Bu gerçekleştiğinde, oyun deneyimi kötüleşmeye başlar çünkü her şey daha az tepki verir hale gelir ve "lag" yani gecikme yaşanır.
Gördüğünüz gibi, tek tek tick'ler daha fazla zaman almaya başladığında, her şey "sağa kayar" ve aynı zaman diliminde daha az oyun tick'i gerçekleşir. İşte bu yüzden sunucu geciktiğinde, her şey daha yavaş işler.
Bu noktada TPS (saniyedeki tick sayısı) ve MSPT (tick başına milisaniye) değerlerinin nereden geldiğini de görebilirsiniz.
Yukarıdaki örnekte:
- Spark, TPS'yi 17 olarak raporlar çünkü bir saniyede sadece 17 tick işlenebilmiştir.
- Spark, minimum MSPT'yi yaklaşık 20 ms (bu iyi!) ve maksimum MSPT'yi yaklaşık 80 ms (50 ms'den fazla, bu kötü!) olarak bildirir.
Spark Profilinde Tick'ler
Spark profillerinde, tick döngüsünü net bir şekilde tanımlayabilirsiniz; genellikle bu döngü profilde en üstte görünür!
Yukarıdaki örnekte, waitForNextTick() işlemci aktivitesinin %81'ini "sunucu akışında" oluşturuyor. Bu harika! Bu, sunucunun her tick için ayrılan 50 milisaniyenin yaklaşık %80'ini hiçbir şey yapmadan geçirebildiği anlamına geliyor. Bu iyi bir işaret, çünkü sunucuda boş kapasite olduğunu gösteriyor.
Eğer sunucuda bir aktivite artışı olursa (örneğin, daha fazla oyuncu katıldığında veya daha fazla nesne/blok güncellendiğinde), sunucunun bu durumu kaldırabilmesi gerekir.
Genel olarak:
- Daha yüksek bir uyku oranı iyi bir işarettir.
- Eğer uyku oranınız %20'den azsa (ve dolayısıyla %80'den fazla tick varsa), sunucunuz oldukça yoğun çalışıyor demektir ve bazı tick'lerde gecikmeler yaşayabilir (bu değerlerin ortalama olduğunu unutmayın!).
- Eğer uyku oranınız %5'ten azsa (ve dolayısıyla %95'ten fazla tick varsa), sunucunuz muhtemelen gecikme yaşıyor ve boş kapasiteye sahip değil.
Son olarak, unutulmaması gereken bir nokta: bu değerler ortalamalardır! Teorik olarak, sunucunuz çoğu tick’i işlemek için sadece 20 milisaniye harcıyor olabilir (bu normaldir), ancak bazen bazı tick'ler için 300 milisaniye harcayabilir (bu iyi değil!). Eğer böyle bir durum yaşıyorsanız, bu "lag dalgalanmaları" ile genel kötü performans arasında bir farktır. Eğer bu durumdaysanız, "uyku" ve "tick" yüzdeleri yanıltıcı olabilir çünkü aşırı değerler ortalama alınır.
Bölüm 2 - Lag Nedenlerini Araştırma
Lag dalgalanmaları, bir dizi tick'in (veya bazen yalnızca bir tick'in) işlenmesi için gereken sürenin uzadığı durumlarda ortaya çıkar. Bu durum, 20 tick'ten birinde bir kez gibi sık sık ya da bir dakikada bir kez gibi nadir gerçekleşebilir. Genellikle, bu durum oyuncuların davranışlarıyla ilişkilidir.
Lag dalgalanmalarının nedenini bulmak, normal profil verilerine bakarak zor olabilir çünkü veriler ortalama alınır. Diğer tüm ölçümler, bu dalgalanmayı "nötralize eder" ve etkisini maskelemeye çalışır.
Neyse ki, Spark bu sorunu çözmek için iki kullanışlı araç sunuyor.
Bölüm 2 - Lag Nedenlerini Araştırma
Lag dalgalanmaları, bir dizi tick'in (veya bazen yalnızca bir tick'in) işlenmesi için gereken sürenin uzadığı durumlarda ortaya çıkar. Bu durum, 20 tick'ten birinde bir kez gibi sık sık ya da bir dakikada bir kez gibi nadir gerçekleşebilir. Genellikle, bu durum oyuncuların davranışlarıyla ilişkilidir.
Lag dalgalanmalarının nedenini bulmak, normal profil verilerine bakarak zor olabilir çünkü veriler ortalama alınır. Diğer tüm ölçümler, bu dalgalanmayı "nötralize eder" ve etkisini maskelemeye çalışır.
Neyse ki, Spark bu sorunu çözmek için iki kullanışlı araç sunuyor.
Adım 1: Lag dalgalanmalarını tespit etmek için /spark tickmonitor komutunu kullanın
Lag dalgalanmalarının nedenini belirlemek için, "düşüş yaşayan" tick'leri diğerlerinden ayırabilmemiz gerekir. Bunun için /spark tickmonitor komutunu kullanabiliriz.
Bu komut, öncelikle sunucunun ortalama tick hızını ayarlayarak çalışır,
ardından:
Bu komut, öncelikle sunucunun ortalama tick hızını ayarlayarak çalışır,
ardından:
- Her bir sonraki tick için harcanan süreyi izler.
- Son tick için harcanan süre ile ortalama süre arasındaki farkı (yüzde olarak) hesaplar.
- Eğer bu fark belirli bir eşiği aşarsa, chat'e bir mesaj gönderir.
Monitörü etkinleştirmek için yalnızca /spark tickmonitor komutunu çalıştırmanız yeterlidir. Varsayılan olarak, eşik değeri %100'dür (yani %100'lük bir artış, bir tick'in ortalamadan iki kat daha fazla zaman aldığı anlamına gelir). Ayrıca, eşik değerini mutlak bir tick süresi olarak belirtebilirsiniz. Örneğin, /spark tickmonitor --threshold-tick 50 komutunu kullanarak 50 milisaniyeyi aşan herhangi bir tick için bildirim alabilirsiniz (bu, sunucunun yakalamaya başlaması veya gecikmeye girmesi gereken noktadır).
O zaman sadece beklemeniz gerekiyor. Eğer yaşadığınız lag, oyun sürecinde belirginse, oyundaki lag etkilerini izleme sonuçlarıyla eşleştirmeye çalışın. Eğer çıktı yeterince duyarlı değilse, daha düşük bir eşik belirlemeyi deneyin; örneğin, `/spark tickmonitor --threshold-tick 70` komutunu kullanabilirsiniz.
Açıklama yapmak için burada "lag dalgalanması" yaratacağım; bunun için WorldEdit kullanacağım.
Gördüğünüz gibi, WorldEdit işlemi sırasında tick süreleri %1000'den fazla arttı!
Açıklama yapmak için burada "lag dalgalanması" yaratacağım; bunun için WorldEdit kullanacağım.
Adım 2: Lag Nedenlerini Bulmak için
--only-ticks-over seçeneği, Spark'ın yalnızca belirli bir eşiği aşan tick'leri profilini çıkarmasını sağlar. Bu, tüm "normal" oyun işlemlerini filtreler ve yalnızca sorunlu lag'li tick'leri bırakır. İyi bir eşik değeri belirlemek için Adım 1'i kullanabilirsiniz; önerim 50 ile 100 arasında bir değer kullanmanızdır, ancak bu her zaman "lag'li" tick'lerin süresinden daha az olmalıdır.
Örneğin, Adım 1'de belirlenen lag'li işlemler 300 milisaniyeden fazlaydı, ancak onların dahil olduğundan emin olmak için 150 milisaniyelik daha düşük bir eşik kullanacağım. Ardından, şu komutu çalıştırın:
/spark profiler start --only-ticks-over 150.
Bu komut, yalnızca 150 ms'den fazla süren tick'lerden örnekler alarak yeni bir profil oluşturur. İşlem tamamlandıktan sonra profil görüntüleyiciyi açın ve profili normal şekilde kontrol edin. Umarım lag'li bölgeler özellikle belirgin olacaktır. Örneğin...
Yukarıda anlatılanları özetleyecek olursak (tekrar ben yazıyorum):
1. Öncelikle, lag'lar sırasında tick süremizin ne kadar olduğunu anlamak için `/spark tickmonitor --threshold-tick 55 --without-gc` komutunu çalıştırıyoruz. (Eğer çok fazla spam geliyorsa, değeri artırın).
2. Lag'lar sırasında tick'lerin minimum uzunluğunu öğrendikten sonra (örneğin, tick uzunluğunun 120 ile 250 arasında olduğunu gösteriyorsa, bu değer 120-150'dir), profili başlatmak için `/spark profiler start --only-ticks-over 100 --timeout 300` (5 dakika) komutunu giriyoruz. 5 dakika sonra sonuçları inceliyoruz.
Genellikle lag'ların nedeni, optimize edilmemiş çekirdek yapılandırmalarıdır. Bu nedenle, yapılandırma optimizasyonuyla ilgili makaleyi inceleyin; böylece hayatınız kolaylaşır. Eğer yapılandırmalarınız iyi durumdaysa, eklentiler bölümüne göz atın; bu bölüme "all" butonuna çift tıklayarak ulaşabilirsiniz (eklentiler bölümü "sources" olarak işaretlenmiştir)
->
En çok lag yapan eklentiler burada gösterilecektir. Onlarla ne yapacağınızı kendiniz karar verirsiniz, sanırım.
Detaylı incelemek isteyenler
adresine giderek ulaşabilir
İyi forumlar
Örneğin, Adım 1'de belirlenen lag'li işlemler 300 milisaniyeden fazlaydı, ancak onların dahil olduğundan emin olmak için 150 milisaniyelik daha düşük bir eşik kullanacağım. Ardından, şu komutu çalıştırın:
/spark profiler start --only-ticks-over 150.
Bu komut, yalnızca 150 ms'den fazla süren tick'lerden örnekler alarak yeni bir profil oluşturur. İşlem tamamlandıktan sonra profil görüntüleyiciyi açın ve profili normal şekilde kontrol edin. Umarım lag'li bölgeler özellikle belirgin olacaktır. Örneğin...
Yukarıda anlatılanları özetleyecek olursak (tekrar ben yazıyorum):
1. Öncelikle, lag'lar sırasında tick süremizin ne kadar olduğunu anlamak için `/spark tickmonitor --threshold-tick 55 --without-gc` komutunu çalıştırıyoruz. (Eğer çok fazla spam geliyorsa, değeri artırın).
2. Lag'lar sırasında tick'lerin minimum uzunluğunu öğrendikten sonra (örneğin, tick uzunluğunun 120 ile 250 arasında olduğunu gösteriyorsa, bu değer 120-150'dir), profili başlatmak için `/spark profiler start --only-ticks-over 100 --timeout 300` (5 dakika) komutunu giriyoruz. 5 dakika sonra sonuçları inceliyoruz.
Genellikle lag'ların nedeni, optimize edilmemiş çekirdek yapılandırmalarıdır. Bu nedenle, yapılandırma optimizasyonuyla ilgili makaleyi inceleyin; böylece hayatınız kolaylaşır. Eğer yapılandırmalarınız iyi durumdaysa, eklentiler bölümüne göz atın; bu bölüme "all" butonuna çift tıklayarak ulaşabilirsiniz (eklentiler bölümü "sources" olarak işaretlenmiştir)
En çok lag yapan eklentiler burada gösterilecektir. Onlarla ne yapacağınızı kendiniz karar verirsiniz, sanırım.
Detaylı incelemek isteyenler
Değerli ziyaretçimiz, içeriği görebilmek için
şimdi giriş yapın veya kayıt olun.
İyi forumlar
