Concurrency ve Async

Selamlar;
Flask üzerine çalışırken flaskın limitlerini test etmek istedim aynı anda kaç request karşılıyor falan. Yukardaki kavramlara yabancı olduğum için bir izah istiyorum. Test için soap ui’ın test suiti var(farklı test uygulama önerebilirsiniz) thread sayısını falan belirityoruz (burst simple vs… bir kaç çeşit daha var) burada 50 thread yaptım mesela cpu tavan yaptı makinada ama flask dahili sunucusu hep yanıt verdi. Yaptığım okumalarda flask sunucusunun async olmadığı yazıyor ama concurrent nasıl çalışabiliyor 50 thread gönderdiğimde mesela 2 nci threadda exception oluşması gerekmez miydi. Ya da ben kavramsal olarak yanlış mı düşünüyorum concurrency ve async arasında bir bağ yok mudur. Terimsel olarak concurrency ve async nedir tam olarak. Aradım fakat yazılanlardan net olarak bir sonuç çıkaramadım. Teşekkürler.

Evet biraz daha araştırdım. Çalıştırdığım metod çok hızlı olduğundan ben bu farkı görememişim. metodu yavaşlatmak için time import edip time.sleep(100) dedim. Böyle yapınca flask suncusu her gönderdiğim requeste bir önceki request sonlanana kadar cevap vermedi. daha sonra flask’ı run ettiğimiz
app.run(host=‘localhost’, port=800, debug=True)
bu söz diziminin werkzeug parametrelerinin incelediğimde
app.run(host=‘localhost’, port=800, debug=True, threaded=True)
olarak yapılabildiğini gördüm. Epey heyecanlandım tabi ama yine hüsran. thread parametresi bir işe yaramıyordu. Sonra debug true bunu false yaptım şükür ki sonunda app concurrency olarak çalışmaya başladı. Flask async olarak concurrency halde çalışabiliyor olduğunu bu sayede anlamış olduk :slight_smile:

Concurrent ayni anda calisan sey. X basladi, X bitmeden Y basliyorsa X ile Y concurrent. Hakikaten ayni anda calisiyor olmalarina gerek yok, ayni zamanda (eszamanli/beraber) calisiyorlar.

Async = asynchronous = bitimini beklemen gerekmeyen sey. Bir seyi async calistirabiliyorsan onunla concurrent’sin (cunku sen bitmeden onu baslatabiliyorsun). Bitimini beklemeden concurrent bir seyler yapabiliyorsun.

Nasil bir exception bekliyorsun?

Ozellikle araya network stack’i girdiginde islemlerin siralanmasi cok normal. “Ayni anda 1 kisiye hizmet eden” sunucu 2. geldiginde yangin cikarmak zorunda degil. Bekletebilir.

Bu terimleri senin anladigin sekilde aciklama sirasi geldi sanirim.

Iki kelime tanimiyla oturacak kavramlar degil. Ufak bir diyalog kurmamiz gerekebilir.

Burada gordugun concurrent/asynchronous seylerin hizli olmak zorunda olmadiklari veya single-threaded/synchronous seylerin yavas olmak zorunda olmadiklari.

Sunucu tek thread’li ve senkron bile olsa kullandigi network stack’i, isletim sistemi vs. concurrent ve asynchronous calisabildigi icin bir cok istemciye es zamanli hizmet verebiliyor. (Ilk cevap Atlantik’in altindaki kablolardan gecerken ikinci cevabi uretmeye baslayabiliyor mesela.)

1 Beğeni

Cevap için teşekkürler.
Şöyle bir exception olabilirdi mesela connection refuse veya 404 gibi. Tek thread olması nedeniyle 1 request gittiğinde sunucunun artık busy olması nedeniyle yeni gelen requestlere cevap veremez halde olmasını bekliyordum. Misalen tek thread olarak syn çalışan bir masaüstü uygulamada böyle oluyor. Button altına event yazdınız mesela sleep(10) sonra buttonClick yaptınız diyelim bu esnada o thread içindeki containera dahil edilmiş diğer tüm componentler artık cevap veremiyor hale geliyor diğer bir buton var mesela uygulama sync çalıştığından dolayı butonun event handlerı çalışamıyor.
Diğer kısımları son yaptığım test ile ne bir şekilde anladım yorumlarında desteklemiş oldu fakat yukardaki mantaliteyi çözemedim tam anlamıyla. @aib fyi

404 olamaz, o URL’nin yanlis oldugunu belirtiyor. 429 olabilir.

Ama bu cevabi verebilecek ikinci bir thread varsa neden orijinal istegi tamamlamaktansa 429 dondursun ki?

Oncelikle: Boyle bir uygulama varsa hatali yazilmis demektir. Bu cok uzun suredir bilinen ve cozulebilen bir problem. Ustelik cozumu birden fazla thread gerektirmiyor.

Thread’ler container’larin sahipleri olmaz. “Container event’lere/mesajlara cevap veremiyor” demek daha dogru. Sebebi ana thread’in sleep(10) gibi bir synchronous call’un cevabini beklemesi, evet.

Multithreaded GUI programlarinda ana thread’de/UI thread’inde is yapilmaz.

Neyi cozemedigini bulur ve ifade edebilecek hale gelirsen yardimci olunabilir.

Edit: Pardon,

buna cevap almadan devam etmem ben.

Edit 2: Ve hatta diger cevap bekleyenlere.

Aslında sorduğum soru açık gibi.
Yukarda bahsettiğim single thread konusu sadece örnek amaçlıydı bu sorunu tabiki çözebiliriz onla alakalı bir sorun yok. Merak ettiğim konu yukarda da söylediğim gibi Async olmayan bir yapı nasıl oluyorda henüz önceki işlem bitmeden yeni bir request gönderdiğimizde ulaşılabilir oluyor.
@aib fyi

ikinci request’e ikinci thread bakiyor

Anladım o zaman sunucu ayağa kalktığında belli bi threadı kendi açıyor sanırım. bunun bir default sayısı falan vardır herhalde. Eyvallah olay netleşti şimdi requesti karşılayan yer n tane thread açıyor ve gelen requestleri karşılıyor fakat içerdeki yapı async olmadığından her request bir öncekini bekliyor halde oluyor.
Eyvallah çok teşşekkür ederim.