lombak şehidi

gRPC server yazacagiz ve serverimizin cok guclu (o da ne demekse) olmasini istiyoruz. Bu yuzden, bir sekilde gelen requestleri paralel olarak isleyebilen bir yapiya ihtiyacimiz var. Python threading malum, CPU intensif isler icin uygun degil cunku GIL sebebiyle ayni anda birden fazla Python kodu calistirilamiyor. Dolayisi ile mevzubahis CPU gerektiren islemler ise, Python threading aslinda tek thread gibi davraniyor.  Bu durumda official ornege bakabiliriz. Tamam Python threading'de GIL engeli var ama multi-process yapar isek boyle bir engel yok. Ne de olsa her bir process kendi GIL'ine sahip olacak. Ama burada da yuku processlere nasil dagitaracagimiz problemi akillara geliyor.  Port Sharing Resmi ornekte, yuk dagitma islemini butun process'leri ayni porta bind ederek saglamislar. Bu sayede yuk TCP katmaninda, isletim sisteminin Kernel seviyesinde yapilmis oluyor. Port uzerine gelen istekler, TCP katmani tarafindan bu portu dinleyen processlere bir round-robin yapisi sekli...

Cok fazla yuk altina girecek olan bir gRPC server isletiyoruz diyelim. Server'i de Python ile yazdigimizi dusunelim.  - Ne gini kisitlamalar yasayacagiz? - Serveri horizontal olarak scale etmek icin ne gini seceneklerimiz var? - Bir de gRPC server local'de calisip, diger desktop uygulamalarina hizmet veriyor ise isler nasil degisir?  Gelin bu kullanim alani uzerinden biraz beyin cimnastigi yapalim. 1. Network Load Balancing Server-side RPC, HTTP 2.0 uzerinde calisan bir iletisim protokolu oldugu icin, HTTP2.0 destekleyen standart load balancerleri kullanabiliriz. En populer secenekler ngix ve envoy proxy olarak gosterilebilir.  Yalniz burada temel bir problemimiz var. gRPC sessionlari sticky bir yapidadir. Yani bir client bir servere bir kere baglanir  ve uzun bir sure boyunca bagli kalir. Request ve response'lar bur mevcut baglanti uzerinden gerceklesmis olur. Bu sayede her request/response icin tekrardan baglanti kurmaya (ve dolayisi ile TCP handshake yapmaya) gere...

Bu multithreading isini cok karistirdilar.  Thread ve Process Thread ve Process, birbirinden bagimsiz olarak calisabilen (teorik olarak) kod parcaciklaridir.  Aradaki fark, ayni program tarafindan olusturulan threadler ayni hafiza alanina erisebilir. Buna karsilik process kendi basina bagimsiz bir program olarak dusunulebilir, Kendine ait hafiza alani vardir.  Bu da demek oluyor ki, thread'ler kendi aralarinda haberlesebilmek icin ekstra bir efora ihtiyac duymazken, process'leri birbiri ile konusturabilmek icin ekstra birseler (gRPC?) yapmak gerekir. Yukarida ayni program tarafindan olusturulan threadler derken bile, aslinda buradaki program, bir process 'tir. Her process primary thread olarak adlandirilan en azindan 1 adet thread'e sahiptir. (Single threaded tabirini hatirlayalim).  Peki neden birden fazla thread'e ihtiyac duyalim?  Kullanici acisindan, birden fazla process'in ayni anda calistirilbilmesi demek, ayni anda birden fazla uygulamayi calistirabilme...