Üye Girişi
Bağlan Google+ ile Bağlan Facebook ile Bağlan
Yeni Kayıt
Tüm Forumlar
  • Tüm Forumlar
  • Web Tasarım - Programlama
  • Yazılım Geliştirme
  • Projeler
  • Bu Konuda
Şimdi Ara

Büyük Çaplı İnternet Sitelerinde Trafik Sorunu

Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
2 Misafir - 2 Masaüstü
5 sn
8
Cevap
0
Favori
283
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
Konuya Özel
0 oy
Öne Çıkar
Cevapla
Sayfa: 1
Giriş
Mesaj
  • Başlıkta da belirttiğim gibi mesela çok yoğun trafiği olan bir internet siteniz var ve bundan dolayı sayfanın sürekli çökmesini nasıl engelleyebiliriz ?

    Yada kısaca server daki yükü nasıl hafifletebiliriz bu arada sadece css kodlarındaki ve js kodlarındaki boşlukları silmek olarak kastetmiyor genel olarak hangi dil bu açıdan kullanılması daha mantıklı olur ve nasıl yapılır ?



  • "Clustering" yapilir. Database tek bir makinede olmaz, farkli makinelere dagitilir. Birden fazla server makinesi olur. Load-Balancer makineleri var. Bunlar pahali ve sadece gelen requestleri farkli serverlara dagitmak icin tasarlanmis cihazlar.
    Bunlar kullanilir. Ornek :http://www.ntsecurity.com/barracuda-products/barracuda-load-balancer.html

    Ayrica SSL cozmek icin ozel uretilen donanimlar var. Normalde standart bir server da SSL cozumlemesi yapmaya nazaran cok daha hizli SSL cozebilen cihazlar da kullanilir. Uzun vadede cok fark yaratir bu cihazlar. Turkiye deki buyuk bankalarin hepsi kullaniyor bunlari.

    In memory clustering adi verilen baska bir yapi daha var. O da ornegin server1 'de memory de saklanan A objesi degistigi zaman, tum diger serverlarin memory sinde de degisiyor. Bu yapi hem Cache hizi sagliyor hem de database e yuklenmemis oluyor serverlar. Ornegin Oracle Coherence teknolojisi :http://www.oracle.com/technetwork/middleware/coherence/overview/index.html

    Bunlarin ucretsiz alternatifleri de var elbette.

    Bir de ek olarak "genellikle" cok fazla yuk beklenen web servislerini "stateless" yaparlar. Yani response almak icin server1 e gitmen ile server2 ye gitmen arasinda bir fark olmaz. Eger bu yaptigin is sebebiyle mumkun degilse yani session kesinlikle tutman gerekiyorsa LoadBalancer makinelerini "StickySession" adi verilen ayarlamalar yaparak surekli ayni server'a yonlendirirsin.

    Yani atiyorum Ahmet server1 e baglandiysa, tum requestlerinde server1 e baglanmaya devam eder. Cunku artik Ahmet'in session'i server1 de olusturulmustur.

    Bazi web siteleri bu session bilgisini da database de tutar, bazilari in memory cache de tutar. Bazilari stickySession yapar yalnizca tek bir server 'da tutar. Trafige ve yapilan ise gore degisir bu mimari.

    Bu konu genel olarak "Scalability" adi altinda incelenir. Yani sen bir programlama yaparken yazilim muhendisi olara; bugun 20 kisiye hizmet verecek sekilde yazsan bile, yarin bir gun 2 milyon kisiye ulasirsan nasil hizmet verecegini planlayarak yazarsin. Mumkun oldugu kadar distributed yapabilecek sekilde kodlayip ona gore bir mimari olusturmak en esnegi olur. Ama daha pahali olur elbette.

    Cogu proje icin 1 tane server kullanmak isi cozer. Trafik artinca server' in donanimini yukseltirsin. Daha fazla RAM, CPU vs isi kurtarir. Buna vertical scaling denir. Yani ayni makineye donanim ekleyerek cozersin. Ancak bir noktadan sonra f/p orani cok kotu bir hal alir. O noktada "horizontal scaling" yapman gerekir. Yeni bir makine eklersin. 2 server, 2 database olur. Bu sekilde yapacaksan eger, bastan buna uygun programlama yapman gerekir ki sonradan astari yuzunden pahaliya cikmasin.

    JS kodunu minify etsen yeterli olur cogu zaman, zaten JS kodu serverda degil client ta calisiyor. Ama gunde 2 milyon kullanicinin geldigi bir server da ic ice 4 tane for loop yazdiysan bir seyleri yanlis yapiyorsundur ( genel olarak )

    < Bu ileti tablet sürüm kullanılarak atıldı >




  • Mephalay M kullanıcısına yanıt
    Yani web sitesini kodlarken kullanılan dilin öneminden çok kullanılan server'ın özellikleri daha önemli
    ayrıca teşekkür ederim çok bilgilendirici bi yazı olmuş
  • Cleous kullanıcısına yanıt
    Evet aslinda cok buyuk olcekte bir trafikten bahsediyorsak zaten muhtemelen tek bir dil kullanilmiyordur. Bazi isleri python scriptle hallediyorsundur atiyorum, server in kendisi Java'dir belki, server in onunde Apache gibi bir baska server requestleri karsiliyordur ( C ile yazilmis ) , hepsinin onunde loadBalancer vardir vs vs.

    Genelde amacin neyse, o isi halledecek en efektif yol ne ise onunla yazarsin. Yani soyle genel gecer bir seyden bahsetmek zor: "Cok fazla trafik bekledigin siteyi php ile yazamazsin " . Duruma gore degisir bunlar. Ornegin facebook PHP ile basladi.

    Ekibine gore, kullanacagin teknolojiye gore bir seye karar verirsin. Eger hosting windows olacaksa, MSSQL kullanacaksan asp c# ile yazmak daha mantiklidir belki de.

    < Bu ileti tablet sürüm kullanılarak atıldı >
  • Hocam Merhaba, Network konusunda bilgilisiniz sanırım. Benimde buna benzer bir sorunum var aslında. R10 forum'da detaylı olarak anlattım, sağolsun birçok yardım eden oldu fakat hala bir sonuca varılmadı ne yazikki. Asıl sorun ise Windows ve C# ikilisine bağlı kalmam... Belki Node.JS ile veya C++ ve Linux ile çok kolay bir şekilde çözülebilecek bir sorun fakat bilgi eksikliğinden diyelim 3 yıldır askıya aldım o sorunu (: Clash of Clans 'da Java server kullanıyor fakat nasıl 500 Milyon kullanıcıyı hiç hatasız, kusursuz ve çökmeden handle edebiliyor anlayamıyorum. (: Aklımda çok deli sorular var yani. :D

    Konum burada ;http://www.r10.net/dedicated-server-amp-co-location-server/1575221-c-cluster-load-balancing-parallel-server-tasarimi.html




  • Dentrax D kullanıcısına yanıt
    Konuna goz gedirdim, C# kullanarak da yapabilirsin ama bu altyapiyi Turkiye de yapmak cok pahaliya mal olur. AWS uzerinden yapmak daha kolay. AWS sana scale etme sistemi de sagliyor, kurdugun server a load balancer ekleyebilirsin, yeni server ekleyebilirsin vs.

    Sorularini buraya kopyaliyorum, bilgim dahilinde cevaplari vereyim.

    quote:

    Soru 1 :

    Şimdi, örnek olarak benim 11 adet sunucum olsun. Her 2'si farklı şirket, farklı ülke, farklı alt yapı. 1'i ise DB server.
    2 Server - A Ülkesi - AANET
    2 Server - B Ülksei - BBNET
    2 Server - T Ülkesi - TTNET (Allah Korusun)
    ...
    1 Server - D Ülkesi - DB Server

    Tek veritabanı sunucusu sorun çıkarabilir, kapanırsa oyun sunucuları iletişim kuramaz, bilgiler RAM'de durur, bir süre sonra hata verip çökebilir. Bu çok riskli birşey. Büyük şirketler bu sorunu nasıl çözüyor ?


    Soru 2 :

    Eğer ben game-server için güncelleme yapmak istesem, bütün sunuculara tek-tek girip hepsini ayrı ayrı mı güncelleyeceğim ? Bu çok mantıksız. Adamın 100 sunucusu varsa ? 100 adet ayar.ini dosyası demek. Hepsini tek tek değiştirmek çok uzun sürer, aynı anda olmaz.

    Soru 3 :

    Client bağlandığı zaman rastgele bir server seçecek. Bu client tarafına yazdığım IP adresleri yardımı ile olacak. Peki oldu ya, şanstır, eşit şekilde paylaşılmadı, %90 A sunucusuna bağlandı. Bu büyük bir sorun demek. Bu sorunu çözmek için sunucular arası bağlantı gerekir. 100 Sunucu olsa, her sunucuya 99 adet diğer sunucuları tutan bir liste yapmak gerek ki, sunucu dolduğuna yakın, kullanıcının "session" dediğimiz durumu diğer sunucuya göndersin. Bu sorun nasıl çözülecek ?

    Soru 4 :

    Load balancing ve cluster arasında fark tam olarak nedir ?

    Soru 5 :

    SUPERCELL firması, AWS kullanıyor. Load-Balancing olaylarını otomatik yapıyor sanırım. Fakat sadece bunu biliyorum, arkada derin bir ayar var. Böyle bir sistem yapan kaynak vs. varmı ?

    Soru 6 :

    Can alıcı nokta, matchmaking sistemi. Evet. A kişisi odayı A sunucusunda kurdu , 30 sn'dir bağlanan birisi yok, biri(leri)ni bekliyor. Peki client B sunucusunda, teknik olarak A kişisinin kurduğuna bağlanması için bulunduğu server'dan A sunucusuna taşınması gerekir ki bu boşuna makineye bağlanma demek. Zaten kesinlikle ve kesinlikle oyuncular karşılıklı oynayabilmesi için aynı sunucuda olması gerekli. Örneğin CS'go da oyuna bağlanırken sol tarafta, kaç server olduğu (gerçek sunucu değil, 16 kişilik oyun sunucusu), kaç oyuncu olduğu vs. herşeyi topluyor, biliyor. Matchmaking sistemini nasıl tasarlayacağım ? Her sunucuda boş bir list oluşturup mu bakacağım ? Bu yapılır fakat tek sunucu üzerinden olur. Onlarca sunucu ile nasıl yapacağım ?

    Soru 7 :

    Bunları yapanlar biliyorum ki büyük firmalar, büyük üstadlar. Fakat hizmeti sağlayan, kullandıkları servis vb. aynı şirketin ve bizde kullanabiliriz diye düşünüyorum, ya da bu hizmeti yapacak firmalar varmı ?


    1) Veritabani clustered olmali ; Atiyorum 3 tane server Mysql server i olarak calisacaklar ( Ya da MSSQL artik her ne kullanacaksan ) Veritabani replication teknolojisi kullanilmali burada. Yani herhangi bir server a yazilan digerine de yazilacak. Tek veritabani dedigin gibi riskli, ayrica HDD hizlari malum, o kadar read-write i kaldirmaz. Bu yuzden replication ve clustering sart.

    Veritabaninin onunde bir "Cache" teknolojisi olacak. Bu senin surekli read-write yapmanin onune gecer. Cok hizli sekilde okuma yapabilirsin. Buna 2nd level cache deniliyor. Java ile de yapsan, C# ile de yapsan Hibernate gibi bir framework ile bunu kullanabilirsin. Linkedin ornegin hayvan gibi kullanici datasini bu sekilde sakliyor. Ancak oyun icin bu ne kadar gerekli bilmiyorum. Oyunlarda cunku surekli DB ye yazma olmaz. Oyun oncesi ve sonrasi ( skorlari, sonuclari vs ) yazarsin. Belki chat donuyorsa onlari kaydetmek icin gerekebilir, ona sen karar vermelisin. Bunun icin de NHCache gibi teknolojilere bakmani oneririm. (Java icin bu ama C# icin de vardir benzeri diye tahmin ediyorum )http://www.ehcache.org/

    2) GameServer guncellemesini load balancing ve scriptler ile halledersin. Ornegin bankalarda su sekilde yapiliyor: Diyelim ki bankanin 10 tane server i var. Update yapilacagi zaman load balancer ayarlarindan server 1 iptal ediliyor. Server1 update edilinceye kadar hic bir kullanici server1 e yonlendirilmiyor. Var olan tum kullanicilarin server1 ile iliskisi bitince update basliyor. Update basarili olunca load balancer dan server 1 aktive ediliyor. Sonra server 2 ye geciyor sira.. Bu sekilde tamami sequential sekilde hallediliyor. Unix scriptleri ile tum sistem otomatize ediliyor. Yani tek bir script calistiriliyor, 3-4 saat suruyor tum bu update isleri.

    Ayrica 1 tane server yazmak da yanlis bir mimari olur. Login Server, Matchmaking Server, Gaming Server gibi segmentlere ayirirsan daha kolay halledilir. Blizzard boyle yapiyor ornegin. Login olurken login server larina baglaniyorsun, oyuna gectiginde o oyunun gaming server i hangisi ise ona baglaniyorsun. Eger server degisince eski client'lari dogru calismayacaksa client update edilmeden oynayamazsin gibi bir hata veriyor. Bu sistemi oturtmak gerekiyor.

    3) Load Balancer lar bu paylasimi kendisi yapiyor. Round-Robin olarak ayarlarsan ilk gelen kullanici 1. ye , ikinci 2.ye vs gibi dagitir. Istersen sesion bazli ayarlarsin, hangi server da session azsa ona yonlendirir ve hep ona gelmeye devam eder. Istersen 1 tane server a %70 daha fazla yonlendirir. Ornegin server1 cok guclu fakat 2 o kadar guclu degil. Bunu da ayarlarsin. Bunu LoadBalancer donanimi kullanmadan yazilim yolu ile yapmak da mumkun. Apache nin loadBalancing i baya iyi ornegin. Nginx de benzer sekilde. Eger sticky session yaparsan kullaniciyi baska server a yonlendirmez. Ayrica bu loadBalancer lar akilli cihazlar, server4 coktugu zaman ona yonlendirme yapmazlar. (Surekli ping atiyorlar 30 sn araliklarla, bunu da ayarlayabiliyorsun ) IP bazinda yonlendirme yapmana gerek yok yani.

    4) Cluter, ayni isi yapan birbirinin kopyasi programlarin farkli makinelerde ya da ayni makinede farkli instance lar ile calistirilmasi. Load balancing, gelen requestlerin farkli endpointlere dagitimi. Clusterin varsa eger senin yuku dagitabilecegin endpoint sayisi artmis olur. LoadBalancing yoksa clustering yapmanin da bir anlami kalmiyor dogal olarak. Clustering dolmus hattindaki dolmus sayisi. LoadBalancing dolmus hattinda bekleyen amcalar var ya, sen araba 1 e bin, sen araba 2 ye bin diyen. Iste onlar : )

    5) AWS nin kaynaklari cok fazla. Her sey yaziyor orada. Ama sistemi kurmak biraz karisik. Adamlar cok elastik yapmis sistemi, cok ucuza baslayip ihtiyaclarin buyudukce degistirebilirsin. Sadece bu sorunun uzerine mini bir kitap yazilabilir. Cok detayli cunku. Farkli server modelleri var. CPU agirlikli segmentler var, RAM agirlikli var vs. Ama 1 tane server ile baslayip, LoadBalancer ile beraber calisan 20 server a kadar cikabilirsin. AWS nin guzelligi de reliable olmasi. Internet sorunu, DDOS korumasi vs gibi seylere kafani yormana gerek kalmiyor.

    6) Bir tane Matchmaking cluster i olacak. Bu cluster gaming clusterinin yuk durumunu bilecek. Ornegin 1 tane gaming server da maximum 10 tane oyun server edebiliyorsan, 7 tane serverin varsa 65 numarali gaming session bosta ise o zaman 7. server'da bos yer varmis gibi dusunebilirsin. Matchmaking server oyunculari bulunca oyun 7. server da baslayacak. Daha guzel bir tasarim da yapilabilir ama acikcasi ben de pek bilgili degilim bu konuda. Tek bildigim matchmaking ile gaming birbirinden farkli iki komponent ve matchmaking gaming hakkinda anlik bilgi sahibi olmali ve ilgili server a yonlendirebilmeli kullanicilari.

    Cluster a eklenen her makine, clusterdaki diger makineleri haberdar eder. Bakin ben de geldim diye. Boylece gaming clusterdaki herhangi bir makineye request atip sorunca "Neresi bos" diye sana soyleyecekler. Cluster in mantigi tum makinelerin "Tek bir server" gibi calismasi. Ayni database de oldugu gibi. Matchmaking yalnizca hangi session odasinin bos oldugunu ogrenecek, sonra oraya yonlendirecek. O session'in fiziksel olarak hangi makineye denk geldigini cluster kendi icinde halledecek.

    7) Benim bildigim bu olcekte bir altyapiyi saglayan en basarili firma AWS. Her ulkede fiziksel server isine girismeden once boyle baslamak en ekonomik yontem olacak. Ancak tabi makinenin fiziksel olarak amerikada olmasi ping sorununa yol acacak. Bu problemi de cozmek icin saglam para gerek. Avrupa, amerika, Asya serverleri olmasi gerek, baglanan kullanicinin ping ine gore gaming session ilgili server da baslamali.

    Login Server - Mathcmaking Server ==> Amerika'da AWS 'de. Gaming Server lar dagitilmis sekilde duruyor. Mathcmaking icin gelen kullanicilarin senin gaming serverlara olan ping lerini biliyor matchmaking algoritmasi. Boylelikle oyuncular icin optimum gaming server a matchmaking karar verip ilgili yerde oyunu baslatacak.

    ---

    Bu arada soyle bir yanlis anlasilma olmasin, load balancer "yalnizca login ve mathcmaking" icin devrede olacak. Oyun baslayinca senin oyun client'in fiziksel olarak hangi server a baglandiysa ( bu bilgiyi mathcmakingden alacak ) sadece onunla iletisimde olacak. Ornek bir akis soyle:

    1) LB ( Load Balancer ) -> Login Server
    2) LB -> MM ( MatchMaking) -> Oyuncu bekleme, optimum server belirlenmesi
    3) MM tum client larin fiziksel olarak gaming server lara olan ping'lerini vs biliyor.
    3) BU noktada MM fiziksel olarak hangi makinede oyunun kurulacagini biliyor artik. Diyelim ki 5.4.5.6:345 adresinde baslayacak oyun. Bunu clientlara dagitacak.
    4) Client -> 5.4.5.6:345 arasinda gecen UDP konusmasi. LB falan yok artik, sadece oyun var.
    5) Oyun bitti, 5.4.5.6 da bulunan server senin mathcmakingServer a request atip sonuclari verecek. Sonrasi yine LB uzerinden Database e kayit vs.

    Yani eger oyun LB uzerinden akarsa cok yanlis olur, gereksiz yavaslama olur, ayrica LB ler UDP uzerinden calisiyorlar mi bilmiyorum. Biraz UDP mantigina aykiri zira.



    < Bu mesaj bu kişi tarafından değiştirildi Mephalay -- 10 Şubat 2017; 23:05:18 >
    < Bu ileti tablet sürüm kullanılarak atıldı >




  • Hocam değerli yorumlarınız için çok teşekkür ederim. Uzun zamandır bu projeyi raf'a kaldırmıştım sırf networking sorunu yüzünden. Bir Blizzard veya Supercell değilim ama onların yaptığı aynı yolu izleyerek de aynı işlevi yapan server ilkel bir şekilde yazılabilir açıkcası. :) Zaten ilk başta öğrenmek amaçlı 3 sunucu kullanarak yapmak yeterli olacaktır, artık gerisi sermayeye bağlı. :D

    Tekrardan teşşekkür ediyorum, bütün bilgileri toplayıp yarım kalan işe devam etmeyi düşünüyorum, belki hemen olmaz ama takıldığım yerde bu konu altından devam edebilirim.
    • 
Sayfa: 1

Benzer içerikler

- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.
Hizmet kalitesi için çerezleri kullanabiliriz. DH’ye girerek kullanım izni vermiş sayılırsınız.
Anladım Veri Politikamız