Bence her soru için timestamp aralığını belirlemek gerek ve rneğin 60 saniye ise cevap süresi 600 parçaya blüp hashlemek gerek. (sallıyorum 188233275235 timestamp için bir hash oluşturursun ) Hashleri adama soruyla beraber gnderip, cevaba dokunduğu an için gerekli hash ile beraber, cevabı delay ederek de alabilirsin. Hatta bu şekilde soruyu bile delay ederek parça parça gnderebilirsin insanlara. Bilmiyorum tabi nasıl bir yapı var da. seni 4 kere dverim yarın

Arkadaşlar bir çok şeyi zetlemişler. Benim de aklıma gelen en büyük maliyet boxing unboxing ve JSON decode/encode işlemleri. Basit gibi grünse de bu maliyetler yüksek request ve response değerlerinde yüksek bir işlem yükü gerektiriyor. 50k r/s sahip olan bir sistem geliştirmiştik bir ekip ile orada JSON yerine messagepack2 kullandık. Hem işlem süresi hemde trafiği çok ciddi optimize ediyor. Benchmarking sonuçlarına internetten erişebilirsin. Buradaki tek dezavantaj debug ederken JSON gibi rahat debug edemiyorsun. Veriler anlaşılır bir şekilde okunmuyor . Backend de Crystal kullanmışları sebebini bilmiyorum ama o dnemlerde go pek popüler değildi. Adamlar. NET standart ile geliştirdikleri servisi Crystale taşıdığında sunucu maliyetinin nerdeyse %70 seviyesinde düştüğünü sylüyorlardı. Tabii ki de kalkıp Crystal ğrenmeye gerek yok bu aşamada sadece aklıma geldi. Belki ağır yük altında olan servislerini Crystal ile kodlayıp farklı makine de farklı bir servis ile hizmet verebilirsin diğer basit servisler. NET de REST API olarak kalır. Micro service mimarisi ile kod geliştireceksen kesinlikle g-RPC neririm. Yakın zamanda hem backend hem de frontend de deneyimledim. Servislerin arası haberleşmede zaten muazzam seviyede performanslı e birde sunucu<->client arasında çift ynlü haberleşme var . Performans olarak bayağı iyi. Zaten RPC yapıları çook çook nceden kullanılan yapılar. Google RPC ile RPC entegrasyonunda bir çok işlem amaleliği ortadan kalkıyor. RPC de ki tek sorun bence WEB tarafında araya bir proxy server eklemek zorunda kalmak. Aradaki proxy server http 2.0 dan http1.1/1.2 convert işlemi yaptığından performansa biraz etki ediyor açıkcası. O da zamanla kalkacaktır tabii. Browser http2.0 desteğini verdiğinde aradaki proxy de kalkacak miss gibi yağ gibi bir sistem olacak. @TeRRoR Web ya da Mobil tarafta bahsettiğin gibi optimizasyona gerek var mı ki hocam? X bir kullanıcının microsaniye seviyesinde daha kısa beklemesi ne gibi bir avantaj sağlar ki? Neden IO işlemlerinden kaçınmalıyız merak ettim doğrusu. Yani hangi senaryo da patlar? Localstorage de tutsak ne direkt singleton sınıfta tutsak ne. Elbette singleton olarak tutarsak sürekli IO işlemi yapmayarak performansı arttırırız ama bu optimizasyon şart mı onu merak ediyorum. Sonuçta tek bir işlem ve tek bir kullanıcı. Bir dngü içerisinde IO işlemi yaptığımız durumda belirtilen kısma optimizasyon yaparız. Dngü içerisinde sürekli IO işlemi yapmak yerine tek seferde değişkene at kullan mantıklı da tek seferlik bir iş için gerek var mı ki? Daha doğrusu maliyeti O ya da daha fazla yük gerektirecek işlemler için kesinlikle IO dan kaçınılmalı bunda aynı fikirdeyim fakat maliyeti O(1) olan bir işlem için optimizasyona girmeye gerek var mı? bunu ğrenmek istedim. MhmdAlmz tarafından 09/Tem/23 10:47 tarihinde düzenlenmiştir Andolsun kuşluk vaktine ve dindiği zaman o geceye ki, Rabbin sana veda etmedi ve darılmadı! Ve kesinlikle senin için sonu nünden daha hayırlıdır. ileride Rabbin sana verecek de hoşnut olacaksın! O, seni bir yetim iken barındırmadı mı? Seni, yol bilmez iken yola koymadı mı? Seni bir yoksul iken zengin etmedi mi? yle ise, sakın yetime kahretme ! El açıp isteyeni de azarlama! Fakat Rabbinin nimetini anlat da anlat!

Hoca şifreli local çzümleri denemeye ne dersin mesela 5. Harf alfabenin sonuna doğru gitsin ve z 1 sn yi temsil etsin y 2 sn ve bunun gibi. Herkesin de appında timer olsun emirhan-exp tarafından 11/Tem/23 17:49 tarihinde düzenlenmiştir

Bir mobil uygulama var. Aynı anda 10.000 tane kişi var içerde. Hepsine bi soru soracağım. Cevabı aynı anda 10.000 kişi de sunucuya gnderecek. En hızlı doğru cevap verene "cevap verme süresini" ve doğru yanlış bilgisini dneceğim. Yani 10.000 kişi request gnderecek 10.000 kişiye tak diye response dnmem lazım. Bunu nasıl yaparım? Flutter + Web api ile sunucu üzerinden request leri karşılayamam bence. Sunucu yavaş çalışır byle olmamalı sanki. Flutter + Web api + RabbitMq + Response şeklinde mi yapmam lazım. Ya da socket mi kullanmam lazım. Burada bana basit bi çizim yapabilir misiniz? Yada telefonumu versem iki dakka kullanmam gereken teknolojileri syleyebilir misiniz? Sadece konsepti anlasam yeter detay bilgi istemiyorum. https://www.youtube.com/watch?v=WC3-71NKwPw

acemi-webci bunu yazdı hocam web api için; tanımladığın soruyu, cevabı ve zamanını hem db hem de bellekte tut. soru endpointine gelen isteğe bellekten direkt soruyu gnderirsen db iodan kaçmış olursun. cevap endpointinde bellekteki cevabı ve zamanından hesap yapıp kullanıcıya response verip requesti tamamlasın bu sırada cevabı queue a gndersin. queue ile arkadan cevapları toplarsın dbye. Başta mantıklı geliyor ama belli bir kotası olması lazım sanki bu dediğinin, 5gb ramlik mesela. teki türlü ter makine ciyak ciyak. end tarafından 09/Tem/23 21:07 tarihinde düzenlenmiştir 0x0480 takilin madem

Veritabanına kullacak mısın? App tasarımı nasıl? Duruma gre bunlardan birini veya ikisini aynı anda kullanacaksın; Redis / RabbitMQ / Apcahe Kafka / ZeroMQ... CPU, Ram ve networking iyi olduğu sürece 10k talep fazla değil. Kolay gelsin.

hocam web api için; tanımladığın soruyu, cevabı ve zamanını hem db hem de bellekte tut. soru endpointine gelen isteğe bellekten direkt soruyu gnderirsen db iodan kaçmış olursun. cevap endpointinde bellekteki cevabı ve zamanından hesap yapıp kullanıcıya response verip requesti tamamlasın bu sırada cevabı queue a gndersin. queue ile arkadan cevapları toplarsın dbye. ...

Hepsine ayni anda response donmen gerekiyorsa araya bi queue sistemi koymanin anlami olmaz. Bu arada anlik 10K request cok buyuk bir sistem degil. Golang ile sistem memory kullanimindan kacip yuksek sayilarda requestlere cevap vermen kolay olur. Yine de concurrency yakalamak istiyorum dersen bir Load balancer ile bu isi 3 5 belki 10 kucuk makineye dagitmak daha hos olur. Frontend tamamen sana kalmis. Socket senin client ile sunucu arasindaki iletisimini hizlandirabiliriz ama bu durumda sunucu 10K socket connection'ini ayni anda acik tutmaya calisacaktir ki bu da kullandigin server paketine gore memory ve cpu sorunlari ciktartabilir. 10K kisiye ayni anda donmek yerine queue yapayim dersen orada o zaman RabbitMq isin icine giriyor olacak. Ama ben tak diye donucem dersen queue'dan uzak durman lazim. Queue seni horizontal'da sabit tutup verticalde artisa neden olacaktir. Senin aradigin ise vertical i sabit tutup , horizontal'da anlik cevap vermek. EDIT: Sistemini Go, gin, gorm gibi paketler ile kurarsan 512Mi 0.5vcpu lu bi makine ile anlik 10K gibi bi request saysiini karsilaman cok zor olmayabilir. ndmylmz tarafından 09/Tem/23 02:41 tarihinde düzenlenmiştir Sistemi de kapattım ama PHP konusunda hala yardımcı olurum // Boş gezenin boş kalfası - ğrenci - YTÜ

Websocket, kuyruk yapısı da iş grür

Yapman gereken ilk şey 10k/s requesti simule etmeyi ğrenmek. Çünkü aksi taktirde burada hepimiz atarız tutarız. Benim ilk aklıma gelen şey latency. Kullanıcı cevap verdiğini ve bu cevabın sunucu tarafından en kısa sürede kayıt altına aldığımızdan emin olmalıyız. Cevabı biraz bekleyip sonra dnsekte olur. Bu noktada ilk mobil uygulamada sunucuya isteğini gnderirken mümkün mertebe minimum complex kod yazman lazım. rneğin localstorage'dan token i okumak yerine bu sayfada kullanıcı geldiğinde token bir değişkene atanmış olmalı. IO'dan kaçın. Sonrasında bu işlemi async olarak tanımla hatta compute fonksiyonu ile çağır bunu. Sonrasında buradaki tojson ve json body'i ufak tut. Backende gelincede durum illaki dağıtık mimariye uygun olacak şekilde tasarlanmalı. Fantazi yapıp go, rust, node js deneyebilirsin ancak web api işini gayet grecektir diye düşünüyorum. Burada yapacağın şey websocket açmak. Kullanıcı daha soru cevap aşamasına gelmeden sockete bağlanmış ve dinliyor olmalı. bylece handshake maliyetini nceden demiş oluyoruz. Backend async şekilde mesajı alıp zaman kaybetmeden queue'ya atmalı. Yarışma sonlandığında standart sorting algoritması ile hesap yapıp tüm kullanıcılara kazanıp kazanmadığını dnebilirsin. Sorunun gnderilmesi kısmını unutmuşum. Bunuda yine socketten kullanıcılara gndereceksin. Burada 10k kullanıcıya ne kadar sürede soruları ulaştırabileceğin işi sıkıntılı burada belki online game dev'lerin yaptıklarına bakmakta fayda var adamların rutini bu iş. Bence çokta şaapma çzülür mevzu. TeRRoR tarafından 09/Tem/23 05:16 tarihinde düzenlenmiştir herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

Merhabalar, 10K req/sn düzgün yazılmış bir API için abartı bir yük değil ancak tahmin ediyorum response için bir yorumlama adımı daha var. Flutter tarafını bilmemekle birlikte işin mimari tarafını gelen requestlere gre yorumlayacağım. Kullanıcılara gnderilen sorunun yanıtı, /api/response endpointine gelecek. Bu endpoint veritabanına her kullanıcıya ait yanıtı ve tarihi INSERT edecek. Aynı zamanda doğru yanıt için SELECT atarak, gelen verileri API tarafında yorumlayıp, kullanıcıya gsterecek. Kaba hesap ile, 10K API req/sn10K Insert/sn10K Select/sn 1 saniye içerisinde, eski tip mimari ile 30K işlem gerçekleştiriyorum. Ben olsam, API için request ve response tarafına ayrı bir microservice olarak yaklaşarak Kubernetes tercih ederdim. Ingress gücünüde kullanarak, aksiyon süresinden nce manuel scale ederdim ki riski minimize edeyim. Konunun başında da dediğim 10K req/sn yüksek bir rakam değil ancak 10 küçük pod ile, her poda 1K yük gibi hesaplardım. Probe tarafına hiç girmeden, olurda 1-5 saniye arasında sürecek aksiyonda bir tarafım patlarsa kalan podlar yaşamına devam edecektir. Ancak, veritabanı hala hayattaysa Ayrıca, kullanıcılarım bugün 10K, yarın 50K olabilir; kolay scale etmem gerekiyor. Mutlaka aramızda sağlam DBA arkadaşlar vardır, benim DBA arkadaşlardan duyduğum/grdüğüm/tecrübe ettiğim kadarıyla bu rakamlar iyi kurgulanmış, gerekli kaynaklara sahip veritabanı sunucusu için hafif. Yine de bir veritabanı bağlılığı yoksa, bu tarz yüklerde MongoDB neriyorum. Ancak, daha basit olsun, işimiz kısa yoldan çzülsün tarafında iseniz Redis'i tek geçerim :) RabbitMQ ya da Socket, yukarıda yazdıklarım gibi bir yntem, zellikle Socket anlık response için kıymetli ancak, sorunuz ekranıma geldi ve yanıtı seçip gnder dedim. Burada 1-2 saniyelik spin süresi her kullanıcı için tlere edilebilir bir değer olarak tahmin ediliyorsa bence gerek yok. Buraya kadar yeterince dallanıp, konuyu komplike hale getirdik :) Bir de şyle ilerleyelim. Flutter > Nginx > MySQL Bu kurguda en zayıf halka 3. adım, veritabanı adımı. Bence bu şekilde kurgulayıp https://loader.io/ gibi (sanırım 10K requeste kadar ücretsizdi, tam hatırlayamadım) endpoint'i yük altına sokarsanız aşağı yukarı durum ortaya çıkacaktır. Bu konuda API için geliştirildiği dil, bahsettiğim veritabanı adımı, API tarafının çalışacağı ortam , bağlılıklar gibi çok fazla parametresi olduğu için kesin konuşmam doğru olmaz fakat konuya bağlı her znenin scale edilebilir olduğundan emin olmanızı neririm. Yalnızca mimari tarafından düşünüp fikir vermeye çalıştım. Umarım faydası olur. Uçamıyorsan, koş. Koşamıyorsan, yürü. Yürüyemiyorsan, sürün. Ama yerinde durma!