WFS öznitelik formatı - CBS OPTİMİZASYONU GEÇMİŞ ÇALIŞMALAR

3. CBS OPTİMİZASYONU GEÇMİŞ ÇALIŞMALAR

4.4.2. WFS öznitelik formatı

OGC gösterim servislerinin öznitelik bilgisi kazanaması için WFS servisinin WMS ve WMTS servisleri ile beraberinde kullanılması gerekmektedir. WFS sorgusu sonucunda oluşan bilginin istemci tarafından işlenerek kullanıcıya sunulması için GML, JSON ve Shape formatındaki standartlar kullanılmaktadır. Bu formatların formunda hazırlanan veriler WFS sorgusuna göre görüntü dosyalarından fazla yer kaplayabilmektedir. Bunun

başlıca nedenleri arasında vektör verilerin çok detaylı olması ve bu verinin tamamına istemcinin ulaşmak istemesi gösterilebilir.

Washington eyaleti vektör test verisinin 45° 32' ve 48° 59' kuzey enlemleri ile 116° 57' ve 124° 48' batı boylamları arasında kalan alan 8 eşit paftaya ayrılarak WFS ile sorgulandığında Çizelge 4.10.’da gösterilen istatistikler ortaya çıkmaktadır.

Çizelge 4.10. WFS sorgu istaristikleri

Washington Eyaleti Vektör Haritası 1:25000 Görüntü Alanı: 180 812 km²

Koordinat Referans Sistemi: WGS84 / Spherical Web Mercator Diskte kapladığı alan: 280,112 mb

Sorgulama Sonucu Toplam Nokta Sayısı: 506 705

WFS sorgu formatlarından ortaya çıkan sonuca göre; sıkıştırma yapılmamış WFS dosya türlerinin, sıkıştırma yapılmış formatlara göre 6 kata kadar daha büyük boyutlara ulaştığı sonucuna ulaşılmıştır. Sıkıştırılmamış dosyalar büyük boyutları sebebiyle ağdaki trafiği artıracaktır. Diğer bir yandan, sıkıştırılmış dosyaların ise sunucu ve istemci bilgisayarındaki işlem gücüne ek yük getirecektir.Çıktı formatları performansının test edilmesi için 2. tip sunucunun WFS hizmeti vermesi sağlanmıştır.1. tip istemci tarafından 8 parçaya bölünmüş Washington vektör verisinin öznitelik bilgileri , sıkıştırılmış ve

0 5 10 15 20 25 30 35

GML2 GML3 JSON SHAPE - ZIP GML2-ZIP GML3 -GZIP JSON - GZIP

Ortalama Dosya Bouyutu (MB.)

sıkıştırılmamış formatlarda çağırılarak ölçüm yapılmış ve Şekil 4.17’de görülen sonuçlar elde edilmiştir.

Şekil 4.17. WFS çıktı formatlarının işlenme süreleri

Sıkıştırılmış formatların boyutları, işlenmemiş formatların boyutuna göre 6 kata kadar varan bir performans avantajı elde etseler de, WFS sorgularının cevaplanarak istemcide işlenmesinde 1,8 kat performans avantajı elde etmektedirler. Ölçümler sonucunda sıkıştırılmış WFS sorgu cevaplarının istemci kaynaklarını ortalama %15, sunucu kaynaklarını ortalama %100 oranında daha fazla kullandığı, fakat genel ortalamada kaynakları daha etkin kullanıldığı görülmüştür.Ölçümler sonucunda küçük bir farkla da olsa , sıkıştırılmış GEO-JSON formatının önde olduğu ortaya çıkmıştır.

Önbellek Mimarisinin Oluşturulması 4.5.

OGC servislerinin çeşitlenmesi ile birlikte harita sunucularının sorumlulukları giderek artmış ve bunun sonucunda;

 İstemcilerden gelen OGC sorgularını hazırlama,

 Verinin temini (Görselleştirilmesi , özniteliklerin temini)

 Verinin kişiselleştirilmesi

 Coğrafi analizleri gerçekleştirme,

 GetCapabilities dosyasının temin edilmesi,

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5

WFS sorgusu cevabının ortalama görüntülenme süresi (sn.)

istemci ağ sunucu

 Mekansal veriler ile öznitelik verilerinni ilişkilendirilmesi,

 Kullanıcı önceliklendirme,

 Yetkilerin belirlenmesi,

gibi birçok fonksiyonu bünyesinde sürdürmeye başlamışlardır.

Harita sunucularındaki bu görev artışı CBS işlemlerinin hantallaşmasına veya gerçekleşmemesine sebep olmaktadır. Bu yüzden sunucu üzerindeki tekrarlanan veya sunucu sorumluluğunda olmayan işlemler CBS uygulamalarındaki diğer bileşenler arasında dağıtılarak , sunucunun asıl görevi olan harita hazırlama işlemlerine kaynak ayırması sağlanmalıdır.

4.5.1. Veri önbellekleme

Harita sunucusunun , istemci tarafından sorgulanan veriyi hazırlaması , sunucu kaynaklarına büyük bir yük getirdiğini bir önceki bölümlerde gerçekleştirilen ölçümlerde değinilmişti. WMS ve WMTS kıyaslaması yapılan bölümde rastgele oluşturulan sorguların

% 25’i aynı mekansal alan denk gelmiştir. Bu duruum başka bir değişle , sunucunun aynı işlemleri tekrardan yapması anlamına gelmektedir. Gerçek kullanıcı sistemlerinde ise bu oran daha da artmaktadır.Tekrarlanan harita oluşturma işlemlerinin sunucuda oluşturduğu yükün azaltılması için CBS sistemlerinde sunucu istemci katmanlarının arasında tekrar işlemlerin denetimini yapacak bir katman bulunması gerekmektedir.

Tekrarlanan WMS ve WMTS görüntülerinin orta katmanda tutularak sunucudaki ağ ve işlem trafiğini azaltmak için önbellek sunucusunun mimaride bulundurulması gerekmektedir. Önbellek sunucusu harita görüntülerini , Matrix Grid yapısı içerisinde eşit boyutlara sahip paftalar ile depoladığından dolayı , QTMGP veri yapısı ve WMTS hizmeti önbellek sunucusu ile verimli çalışacaktır.

Ölçümlerin yapılması için Amazon AWS sunucularından istemci ve önbellek sunucusu için C3.large modeli , harita sunucusu için C3.8xlarge modeli seçilerek Liu ve Nie (2010)

‘nin önerdiği (Şekil 4.18) 3 katmanlı önbellek mimarisi oluşturulmuştur. Bu mimari QTMGP kullanılarak ve kullanılmadan WMS ile WMTS servislerinde yük testine tabi tutulmuştur.

Şekil 4.18. Üç katmanlı önbellek sunucu mimarı

Oluşturulan üç katmanlı önbellek sunucu mimarisi ile yapılan ölçümler sonucunda toplamda 1 032 912 adet harita isteği istemciden sunuculara gönderilmiştir ve 1 036 211 pafta sonucu istemciye yanıtlanmıştır.İlk test önbelleklenmemiş sistem üzerinde gerçekleştirilmiştir ve Şekil 4.19’daki sonuçlar elde edilmiştir.Bir önceki WMS ve WMTS karşılaştırmasının benzeri yapılan testte , 100 kullanıcıya kadar 1sn. altında gerçekleşen cevap süresi 1 sn. üstüne çıkmıştır.Bu durumdaki en büyük etken ; önbelleklenmiş harita olmadığı durumda öncelikle önbellek sunucusu , sonrada harita sunucusunun işlem ve ağ kaynaklarını tüketmesidir.

Cevap sürelerindeki artışa rağmen önbellek sunucusu ile WMTS servisi 5000 eşzamanlı kullanıcıyı desteklenmiş ve bir önceki istemci sunucu mimarisine göre 2 kat daha fazla kullanıcıya hizmet verebilmiştir.Fakat WMTS servisi ile yapılan test 6000 ve WMS servisinde ise 2500 eşzamanlı kullanıcıda sunucuların cevap vermemesinden dolayı sonlanmıştır.Ayrıca bu ölçümde WMS servisinin önbellekleme yapısna uygun olmadığı görülmüştür.Çünkü önbellekte saklanan haritalar Matrix pafta veri yapısında saklandığından dolayı , WMS sorgusunda pafta birleştirme ve kesme görevleri için işlem gücü ve hafıza kaynakları yoğun olarak kullanılmaktadır.

Şekil 4.19. Önbellek mimarisinde birinci test sonuçları

3 katmanlı önbellek sunucu mimarisi ile yapılan 2. deneyde (Şekil 4.20), bir önceki testin önbellek sunucusunda depolanan haritalar temizlenmeden, WMTS ile ölçüm yapılmıştır.

Bir önceki test kurallarının tekrarlandığı bu deneyde 3000 eşzamanlı kullanıcıya kadar cevapların 2 sn. altında kaldığı görülmüştür. Ek olarak , 8000 eşzamanlı kullanıcıya kadar sunucu çalışmaya devam etmiştir.Dezavantajı olarak , 1000 eşzamanlı kullanıcı altında 2 katmanlı mimarinin performans açısından az da olsa gerisinde olduğu gösterilebilir.

Şekil 4.20. Önbellek mimarisinde WMTS için ikinci test sonuçları

1,3 1,6 1,4 1,3 2,3

10 25 50 100 250 500 750 1000 1250 1500 1750 2000 2500 3000 3500 4000 5000 6000

Harita Cevap Süreleri (sn.)

Şekil 4.21. Birinci test harita ve önbellek sunucusu sorgu oranları

Önbellek sunucunun ilk deneydeki performansının verimsiz olmasının öncelikli sebebi, ilk deneyde daha önceden yapılmış bir önbelleklemenin olmamasıdır. Şekil 4.21 sonuçlarında görüldüğü gibi sorguların yanlızca %30’unda geowebcache kullanımıştır. Sorguların %70 kısmı için önce geowebcache daha sonrada geoserver sunucusu sorgulanarak cevap süresinin uzamasına neden olunmuştur.

Şekil 4.22. İkinci test harita ve önbellek sunucusu sorgu oranları

İkinci testte ise, birinci testte %30 oranında önbellekleme yapılmış haritalar kullanılarak deney gerçekleştirilmiştir.Şekil 4.22’deki grafik incelendiğinde geowebcache kullanımı 5500 eşzamanlı kullanıcıdan sonra geoserver kullanımını geçmektedir.Böylelikle hali hazırda işlenmiş olan paftalar harita sunucusunda hazırlanmadan önbellek sunucusu tarafından temin edilebilmektedir.

Sonuç olarak , önbellek sunucusunun mimariye kazandırılması eşzamanlı kullanıcı sayısı artışına katkı sağlasa da , önbelleğe alınmamış pafta sorguları cevapların gecikmesine neden olmaktadır.Bu sebepten dolayı belli bir kullanıcı sayısını işleyemeyerek sunucunun cevap verememesine neden olmaktadır.Bu sorunun çözümü için kullanılması olası paftaları tamamının veya bir kısmının önbelleklenmesi gerekmektedir.

Önbellek besleme mekanizması

Önbellekleme oranını artırmak için 2 yöntem bulunmaktadır. Harita sunucusuna eklenen verinin bütün alanlarının önbelleklenmesi bu yöntemlerden ilkidir.Büyük boyutlara sahip bir verinin bu yöntem ile önbelleklenme süreci günler sürebilmektedir.Ayrıca harita verilerinin sıklıkla güncellendiğini düşünürsek bu yöntemin etkin bir çözüm olmadığı çıkarımı yapılabilir.

Çizelge 4.11. 8 GB raster harita önbellekleme istatistiği [75]

Ölçek Seviyesi

Pafta Sayısı Boyutu (MB) Süre (Saat) Süre (Gün)

14 232,870 4 0 0

15 929,475 14 0 0

16 3,713,893 57 1 0

17 14,855,572 227 6 0

18 59,396,070 906 23 1

19 237,584,280 3625 92 4

20 950,273,037 14500 367 15

Diğer yöntem ise istemci tarafından talep edilen bir bölgeye komşu olan paftaların önbellek sunucusunda depolanmasıdır. Sorgulanan her bir paftanın 8 x Tampon Sayısı miktarındaki komşu paftanın önbellek sunucusunda hazırlanarak depolanması önbellek oranını artırarak harita sunucusundaki işlemleri azaltacaktır.

Şekil 4.23. Tampon=1 için pafta komşu önbellekleme

Önbellek sunucusuna kazandırılan bu yöntem ile 10 dakikalık test sonucunda %33 oranında sağlanan önbellekleyi %46 seviyesine çıkarabilmiştir. Bu orandaki artışın düşük olmasının sebebi; komşu paftalar daha önceden önbelleğe alınmışsa önbellekleme işlemi yapılmadan işlem sonlandırılmaktadır. Bu problemi gidermek için tampon(T) miktarı arttırılabilmektedir. Örneğin Şekil 4.23’te tampon miktarı 1 belirlendiğinde önbelleklenmemiş pafta sayısı 4 olurken, tampon sayısı 2 belirlendiğinde önbellek sunucusuna depolanmamış 17 adet pafta tespit edilmektedir. Tampon miktarının artışı paftalama oranına önemli ölçüde katkı sağlasa da, ilk önbellekleme sürecinde sunucu işlem trafiğini artırarak istemciden gelen sorguları olumsuz etkilemektedir.Bu problemin giredilmesi için istenen paftanın düğüm komşularınınönbellek oranları tespit edilerek en uygun en fazla 4 aday¹⁰ tespit edilir.

10 Izgarada köşeye denk gelen paftaları 3 komşusu olabilmektedir. Ortada bulunan bir paftanında en fazla 8 komşusu bulunabilmektedir.

Şekil 4.24. Komşu düğüm önbellekleme

En az önbellekleme oranına sahip olan komşu düğümlerinin çocukları ve sorgulanan paftanın düğümündeki komşuları önbelleklenir. Önbellekleme sonucunda komşu pafta önbelleklemedeki zaafiyet giderilmiş olur.

Örneğin Şekil 4.24’te sorgulanan paftanın komşu düğümleri 8 adettir. Bu düğümler içerisinde;

 1. Düğüm içerisinde 3

 2. Düğüm içerisinde 4,

 3. Düğüm içerisinde 3,

 4. Düğüm içerisinde 2,

 5. Düğüm içerisinde 3,

 6. Düğüm içerisinde 3,

 7. Düğüm içerisinde 3,

 8. Düğüm içerisinde 3,

önbelleklenmemiş pafta bulunmaktadır. Son olarak sorgulanan paftanın düğümünde 2 adet önbelleğe alınmamış pafta verisi bulunmaktadır.

Şekil 4.25. Komşu paftalama ve düğüm paftalama önbellekleme kıyaslaması

Belirlenen 3 komşu ve sorgulanan pafta düğümü önbelleğe alındığında ise toplamda 12 paftanın daha önbelleğe alınması sağlanmıştır. Aynı örnekte ise komşu pafta (KP) önbelleklemede bu sayı 4 adet paftada kalmıştır. Komşu düğüm (KD) paftalamadaki 4 pafta komşusunun seçim nedeni yapılan testler sonucunda performans ve pafta oranını en iyi veren sdüğüm sayısı olmasındandır.5 komşu düğüm ile yapılan testlerde sunucuların kararsız çalışabildiği tespit edilmiştir.

0 20 40 60 80 100

1 3 5 7 10

Önbellekleme Oranı %

Geçen Süre (dk) T=1 KP 3 KD 4 KD

Şekil 4.26. Komşu paftalama ve düğüm paftalama performans kıyaslaması

Tampon oranı 1 olan komşu pafta önbellekme yöntemi , komşu düğüm önbellekleme yöntemi ile kıyaslandığında 2 kat önbellekleme oranı ortaya çıkmaktadır.10 dk içerisinde 4 komşu düğüm ile yapılan önbellekleme haritanın %93’lük bölümünü önbellek sunucusuna kayıt ederken bu oran komşu paftalamada %50’nin altında kalmaktadır.

Eşzamanlı kullanıcılar ile performansları kıyaslandığında ise otomatik önbellekleme yeteneği olmayan sunucuya göre KP ve KD yöntemlerinin daha başarılı sonuçlar verdiği Şekil 4.26 grafiğinde görülmektedir. 3 KD ve 4 KD yakın sonuçlar vermesine rağmen 4 KD 10 000 eşzamanlı kullanıcı sorgularını cevaplayabilmiştir.Ayrıca ortalamada PK 5.1 sn. ,3 KD 3.7 sn. ,4 KD 2.9 sn. cevap süresi sunmuştur. KD paftalamanın ölçeklendirebilirliğe yapılan ölçümler sonucunda olumlu katkı sağladığı sonucuna varılmıştır.

Önerilen Mimari ve Kıyaslaması 4.6.

Bu bölüme kadar geçen sürede ölçeklendirilebilir ve kararlı OGC mimarisinin oluşturulması için CBS bileşenlerinin ve OGC servislerinin performansını artırmaya yönelik çalışmalar yapılmıştır. Bu çalışmalar sonucunda yeni ve geçmiş çalışmalardaki

1000 1250 1500 1750 2000 2500 3000 3500 4000 5000 6000 8000 10000 0,4 0,6 0,9 0,8 1,2 1,4 3,3 2,2 6,5 8,0 8,5 14,4 18,2 0,0

yöntemler uygulanmış ve ölçümler ile OGC servislerini en verimli kullanan yaklaşımlar ortaya çıakrtılmıştır. Bu yöntemler sonucunda sunucunun üzerindeki sorululuklar azaltılmış ve katmanlar arasındaki haberleşme ızgara sistemi üzerinden yapılmıştır.

Oluşturulan bu mimari ile ortalama 2,9 sn. cevap süresi , 3500 kullanıcıya kadar 2 sn.

altında kabul edilebilir cevaplar ve 10000 eşzamanlı kullanıcı desteği sağlansa da, sunucuda ve ağdaki yoğun işlem trafiği nedeniyle veri kayıpları oluşmaktadır.Ayrıca 10,000 eşzamanlı kullanıcı ile yapılan yük testinde ortalama 17,4 saniye cevap ve 12 dk çalışma süresine ulaşabilmiştir.

Şekil 4.27. 10,000 eşzamanlı kullanıcı ile 20 dk yük testi

Eşzamanlı kullanıcılar ile yapılan yük testinde ise OGC sorgularının 3500 kullanıcı sonrasında hata sayısının artması dikkat çekmiştir. Şekil 4.28 sonuçlarında 10000 kullanıcıda hata sayısının 1600’e kadar ulaştığı görülmektedir. Buda her kullanıcı sorgularının 8’de 1’nin cevap dönmediği anlamına gelmektedir.

10,8 12,1

Şekil 4.28. Sorgulardaki cevaplanamayan veri sayısı

3 katmanlı olarak şekillendirilen bu yapıda kaybedilen zamanın anlaşılabilmesi için 6000 , 8000 ,10000 eşzamanlı kullanıcı istatistikleri ile Şekil 4.29’daki grafik oluşturulmuştur.

Ortaya çıkan sonuçlara göre önbellekte geçen sürenin , ortalama cevap süresinin yarısını oluşturduğu tespit edilmiştir. Burdaki tespitin en önemli sebebi tek bir geowebcache sunucusunun eşzamanlı kullanıcı sayısı arttıkça taleplere cevap verememesinden kaynaklanmaktadır.

Şekil 4.29. Sorgulamada sunucu ve ağdaki geçen süreler

Harita-önbellek sunucu ağı İstemci -önbellek sunucu ağı

Önbellek sunucundaki ve harita sunucusundaki yükün dengelenmesi için katmanlardaki oluşumların ölçeklendirilmesi gerekmektedir.Fakat statik olarak kurgulanan bu yapılandırma kullanıcı sayısındaki artış ile beraber yavaşlama ve sistemin cevap vermemesine , taleplerin azalması ile birlikte maliyetin etkin kullanılmamasına sebep olmaktadır. Bu durumda ölçeklendirilen bir sistemin doğru kurgulandığı söylenemez.

Bu sorunlardan dolayı ağdaki ve sunucu donanımındaki yük dinamik olarak tespit edilerek sunucu ve ağ kaynaklarının artırılması gerekmektedir.Ayrıca ölçeklendirmenin etkin olarak yapılması sağlamak içinse tüm kaynakların homojen bir dağılımda kullanılmasını sağlamak gerekmektedir. Yük dengeleme ve ölçeklendirme (scaling) işlemlerinin gerçekleştirilebilmesi için Eş. 4.17 eşitliği kullanılmıştır.

Toplam Yük = İşlemci Yük Oranı +Hafıza Yük oranı +Ağ Yük Oranı (4.17) Ydonanım (Ycpu+Yram)+Ybandwdith <=1

Eşitliğe göre sistemde bulunan bir kaynağın tamamının veya yarısından fazla kullanımını sistemin kaynaklarının artırılmasını işaret etmektedir. Ölçeklendirme sonrasında ise gereksiz kaynak artışını engellemek için istek sayısı homojen bir şekilde ölçeklendirilen sistemlere dağıtılması sağlanır. Kaynak ölçeklemesinin önemli problemlerinde biri ise ölçeklendirilen sistemin güncel verileri içermemesidir.Verilerin her bir sunucuda eşit olarak bulunması için ise uçtan uca iletişim (peer 2 peer) yönteminin kullanılması gerekmektedir.Ölçeklendirme ve yük dengelemesinin oluşturulan mimaride kullanılması için Amazon ürünleri olan Auto Scaling ve AWS Load Balancer kullanılmıştır.

Şekil 4.30. Önerilen mimari

Önerilen mimarinin Test adımları ve yapılandırması aşağıdaki maddeler halinde yapılmıştır:

 Test Süresi – Test süresi 24 saat olarak belirlenmiştir. Bu süre içinde sanal ölçeklemenin,

 Eşzamanlı kullanıcıların sayısı – Testler 10000 eşzamanlı kullanıcı ile gerçekleştirilmiştir.

 Kabul edilebilir cevap süresi – Sunucuda görüntünün hazırlanma süresi 2 sn. olarak belirlenmiştir. Bu sürenin üstünden kullanıcı deneyimi azalmaktadır.

 Test sonrası yeni ölçümler için sunucular ve istemciler yeniden başlatılmıştır.

 Harita sunucusu için geoserver harita sunucusu kullanılmıştır.

 Önbellek sunucusun için geowebcache kullanılmıştır.

 Önbellek ve harita sunucu katmanları AWS Auto Scale ile ölçeklendirilebilir yapıya getirilmiştir.

 Sunucu ,istemci veağdaki yükün dengelenmesi için AWS Load Balancer bileşeni Eş.4.17 eşitliği ile kullanılmıştır.

 İstatistik için şu bilgiler kayıt altına alınmıştır:

o Toplamda sunucuya gönderilen sorgu sayısı

o Kabul edilebilir sorgu cevabının ( >2 sn.) yüzde kaç olduğu o Ortalama cevap süresi

o Hatalı cevap sayısı

o Ağ ve sunuculardaki geçen süre

 Harita sorgu üretimi – Yapılan tüm testlerde test haritasının (Washington verisi vektör ve raster) tamamını kapsayan alanda rastgele sorgulama yapan yük test aracı

Eşzamanlı kullanıcının harita sorgu benzetiminin gerçekleştirilebilmesi için testler mahallî sunucu ve istemci yerine, Amazon firması tarafından sağlanan AWS (Amazon Web Services) sunucuları kullanılmıştır. Ölçümlerde oluşturulan sorgularda çakışma ve resim işleme algoritmaları yoğun olarak kullanılmıştır. İşlemlerin harita sunucusunda yük oluşturmaması ve başarılı ölçümler alabilmek için Amazon sunucu servislerinin işlemsel gücü olan EC2 (Amazon Elastic Compute Cloud) çözümü seçilmiştir.

EC2 yapılandırması istemci ve sunucu için farklı özelliklerde seçilmiştir:

 Sunucu yapılandırması için; Intel Xeon E5-2680 v2 (Ivy Bridge) işlemci, 60 GB hafıza ve 640 GB SSD özelliklerine sahip C3.8xlarge modeli,

 İstemci için; C3 ailesinde 3,75 GB hafıza ve 32 GB SSD depolamaya sahip C3.large modeli seçilmiştir.

 Mekansla verinin depolanması için 2 adet S3 (Amazon Simple Storage Service) kullanılmıştır.Ayrıca bu iki depolama alanının eşit tutulması için P2P iletişim kullanılmıştır.

24 saat süren ve 10000 eş zamanlı kullanıcı ile yapılan test sonucunda mimaari en fazla 3 kere ölçeklendirilerek yeniden kurgulanması sağlanılmıştır.Bu mimari sonucunda harita ve önbellek sunucuları ile ağda oluşan ortalama yük şekil 4.31 grafiğinde gösterilmiştir.

Şekil 4.31. Ölçeklendirmede oluşan 3 mimarinin istatistikleri

Bulgulara göre önbellek ve harita sunucularında oluşan yük dağılımı dengelenerek sunucuların kapanması veya cevap vermemesinin önüne geçilmiştir.Böylelikle 3 ölçekleme seviyesiyle 10000 kullanıcıya hizmet verilebilmiştir.Bu süre zarfındaki sorgulamalarda oluşan hatalar incelendiğinde ise ortalama hata sayısı 15 olduğu tespit edilmiştir ve bu hata sayısı ortalama sorguların sadece %0,002’lik bölümünü oluşturmaktadır.

Harita-önbellek sunucu ağı İstemci -önbellek sunucu ağı

Şekil 4.32. 10000 kullanıcılı testte sorgudaki hata sayıları

Geçmiş çalışmalar incelendiğinde , yapılan iyileştirmelerin tek bir katman veya bileşende gerçekleştirildiği, OGC sorguları , veri yapısı ve sunucuların uyumunun dikkate alınmadığı tespit edilmiştir. Geçmiş çalışmalarda özellikle önbellek sunucusu kullanımı ve performans iyileştirmelerine yönelik çalışmalarda bulunulmuştur [55-63].Diğer araştırmacılar ise OGC performansı ölçümünü sunucu ve tarayıcı üzerinde yaparak kıyaslamalarda bulunmuştur [21,25,32,35,61]. Bu araştırmaların dışında güvenlik , mobil ,web veya özel bir alana yönelik CBS mimarisi araştırmaları da geçmiş çalışmalarda sıklıkla rastlanmaktadır.

Ayrıca eşzamanlı kullanıcılar ile yapılan yük testlerinin , endüstriyel ortamda kullanılan CBS sistemlerine benzerliği birçok çalışmada dikkate alınmamıştır. Eşzamanlı kullanıcıların, ölçeklendirilebilir bir sistemde performanslı ve kesintisiz olarak OGC servislerinden hizmet alabilmesi için çalışma yapılmamıştır.Bu ölçütler doğrultusunda 3 katmanlı WMS mimarisi ve 2 katmanlı WMS istemci sunucu mimarisi OGC performans iyileştirme çalışmaları, bu çalışma kapsamına en yakın araştırmalardır. 3 katmanlı WMS mimarisi ve 2 katmanlı WMS istemci sunucu mimarisi ile önerilen mimari eşit koşullarda teste tabi tutulduğunda Şekil 4.33 ve Şekil 4.34’teki sonuçlar elde edilmiştir.

0 5 10 15 20 25

2 4 6 8 10 12 14 16 18 20 24

Toplam Sorgu Hata Sayısı

Geçen Süre (saat)

Şekil 4.33. OGC mimarilerinin hata sayıları grafiği

Şekil 4.34. OGC mimarilerin cevap süreleri grafiği

Elde edilen sunuçlara göre 3 katmanlı mimarinin ve istemci sunucu mimarisinin hata sayısında yüksek değerler elde edilmiştir.Bazı noktalarda 5 sorgudan 1 sorguya cevap verilemediği tespit edilmiştir.Ayrıca Şekil 4.34 incelendiğinde ise önerilen mimari dışındaki 2 mimarinin ortalama cevap süreleri kullanıcı deneyimini olumsuz etkileyecek

Sun v.d. (2015) 3 katmanlı WMS mimarisi Yang v.d. (2013) WMS istemci sunucu mimarisi

0 Yang v.d. (2013) WMS istemci sunucu mimarisi

seviyede olduğu bulgulanmıştır.Diğer mimariler ile kıyaslandığında eşzamanlı kullanıcıların önerilen mimari tarafından desteklendiği ve ortalama 1,72 sn. olan cevap süreleri ile kullanıcı deneyimini etkilemediği görülmüştür.Çalışma kapsamında oluşturulan mimarinin eşzamanlı kullanıcı artışını verimli yönetebildiği ve ölçeklendirmeyi en etkin şekilde yapılandırdığı bulgular sonucunda tespit edilmiştir.Çok az kaynak ile kullanıcı deneyimini beklenti üstünde sağlayarak, endüstriyel kullanıma yönelik bir mimari olduğu kıyaslamalar ve testler sonucunda ortaya çıkmıştır.

Çizelge 4.12. OGC mimarilerinin test kıyaslaması

Önerilen Mimari Sun v.d. (2015) 3

Önbellekleme Oranı %98 %78 Önbellekleme

Yok

Oluşturulan QTMGP yapı yapısı ve WMTS sorgusu ile ,önerilen mimarinin istemci ,harita ve önbellek sunucusu çalışma diyagramı Şekil 4.35’deki gibi yapılandırılmıştır.

Şekil 4.35. Önerilen mimari aktivite diyagramı

5. SONUÇ VE ÖNERİLER

Günümüz teknoloji dünyasındaki gelişmeler ile birlikte, istemci üzerindeki işlemlerin asgari düzeye çekilmesi amacıyla, sunucu destekli sistemlerin kullanılması ihtiyacı doğmuştur. Bu gelişmeler ile beraber, Coğrafi Bilgi Sistemleri (CBS) uygulamaları bilgisayar işlemci gücü ve depolama alanı kullanımı göz önünde bulundurulduğunda sunucu tabanlı servislere ihtiyaç duyan önemli alanlardan biri olmuştur. CBS uygulamalarının sunucu destekli hizmet vermesi ile birlikte, sunucu ile istemci arasındaki harita yayınlama ve veri analizi gibi işlemler için gerekli haberleşmenin ortak bir çatıda toplanması için çalışmalarda bulunulmuştur. Bu çalışmalar sonucunda standartlar OGC çatısı altında toplanarak CBS işlemlerinin OGC standartlarına uygun yapılması sağlanmıştır. Fakat, OGC servislerinin efektif olarak çalışabilmesi için harita sunucuları ve istemcilerin yazılımsal bileşenleri; ağ yapısı, sunucu donanımı , kullanılacak veri yapısı ve seçilen OGC servisine göre yapılandırılmalıdır. Özellikle anlık veri isteğinin önemli olduğu ve veri kayıplarının göz ardı edilemeyeceği sistemlerde bu ihtiyaçların coğrafi bilgi

Belgede COĞRAFİ BİLGİ SİSTEMİNDE İSTEMCİ SUNUCU MİMARİSİNE YÖNELİK OGC SERVİSLERİ OPTİMİZASYONU. Murat AKKAN (sayfa 76-115)