İstemci sunucuya istek gönderirken, yanıt aslında hemen sağlanamayabilir. Bu gecikme sırasında, bağlantı herhangi bir nedenle kesilebilir ve istemci, bağlantıyı otomatik olarak yeniden kuracak kadar akıllı olmalıdır.

Ancak başka bir sorun ölçeklenebilirlik var. Bu uzun vadeli bağlantılara sahipsek, sunucu tipik olarak işleme konularını istemciye gerçekten yanıt vermek için iletiler mevcut olana kadar bekleme durumuna alır.

Bekleyen iş parçacıklarına sahip olmak bir ölçeklenebilirlik katilidir, çünkü web kapsayıcısının iş parçacığı havuzundaki çok sayıda iş parçacığı, siz farkına bile varmadan tüm iş parçacığı havuzunuz boşalana kadar hiçbir şey yapmadan bekleme durumunda kalacaktır. Bunun hemen sonucu, sunucunuzun başka herhangi bir istek işlemeyi işleyemeyeceğidir. Bu nedenle böyle bir yaklaşım kesinlikle kabul edilemez.

Ölçeklenebilirliğin anahtarı, engellemeyen G/Ç’dir. Çoğu işletim sistemi engellemesiz G/Ç’yi destekler; bu aslında bir G/Ç kaynağından (diyelim ki bir yuvadan gelen akışlar) okurken veya bu kaynağa yazarken herhangi bir engelleme işlemi olmadığı anlamına gelir.

Bu nedenle, bir akıştan okursanız, veri olup olmadığına bakılmaksızın okuma işleviniz hemen geri döner. Java’da, bloke etmeyen G/Ç, Seçiciler ve Reactor modeli kullanılarak Java Yeni G/Ç (NIO) kitaplığı aracılığıyla kullanılabilir. NIO’ya aşina değilseniz, güzel bir genel bakış var.

Engellemeyen G/Ç’nin ölçeklenebilirlik üzerinde büyük bir olumlu etkisi vardır, çünkü iş parçacıkları çok hızlı bir şekilde iş parçacığı havuzuna döndürülür ve diğer istekleri işlemek için yeniden kullanılabilir. Bu modelde, iş parçacıkları bağlantılara yalnızca veri işleme için uygun olduğunda tahsis edilir, bu da doğası gereği daha iyi bir iş parçacığı yönetim sistemine yol açar.

Web kapsayıcısı tarafından etkinleştirilen engellemesiz G/Ç’ye sahip olmanın, istemciden sunucuya uzun ömürlü bağlantılarla ilgili olarak uygulama ölçeklenebilirliği üzerinde de önemli bir etkisi vardır.

Ek olarak, Lift çerçevesi şu şekilde çalışan Jetty Continuations desteğine sahiptir:

1. Uygulamanız bir istek alıyor ve henüz mesaj olmadığı için yanıt vermek için beklemek istiyor.
2. Jetty Continuation nesnesinde askıya almayı çağırırsınız. Burada Jetty, konteynerde yakalanacak özel bir istisna atacak. Geçerli iş parçacığı, diğer istekleri işleyebilmesi için hemen iş parçacığı havuzuna döndürülür.
3. Bir süre sonra o müşteri için bir mesajınız olduğunu varsayalım. Aynı Devam nesnesinde özgeçmişi çağırırsınız. Bu sefer, Jetty aslında ilk HTTP isteğini yeniden yürütecek ve sunucu uygulamanız, bu istek istemciden yeni alınmış gibi davranacak ve tabii ki uygun yanıtı döndürecektir.

Jetty’s Continuations hakkında daha fazla ayrıntı web sitesinde mevcuttur. Lift uygulamanızı bir Jetty konteynerinde çalıştırırsanız, Lift bunu otomatik olarak algılar ve Devam mekanizmasını kullanır.

Şu anda, diğer kapsayıcılarda, Comet in Lift çalışmaya devam edecek ancak Devamlılıklar desteklenmediği için ölçeklenmeyecektir. Bununla birlikte, Servlet 3.0 spesifikasyonu, Askıya Alınmış İstekler adı verilen ve bu özelliği çeşitli kaplarda kullanılabilir hale getirecek daha genel bir özellik içerir.

Meta kodları
Meta robots etiketi
Google meta keywords
Google Search Console site ekleme

Scala’daki Aktörleri Anlamak

Lift’teki Comet desteğinin öncelikle Scala aktörleri aracılığıyla sağlandığını anlamalısınız. Scala aktörleri, bir aktörün mesajları alan ve gönderen veya yanıtlayan eşzamansız bir bileşen olduğu Erlang Actors modelinin kavramlarına dayanır. Erlang’da süreçler, sanal makineye yerleşik çok basit ve etkili bir mesajlaşma sistemi aracılığıyla da iletişim kurar.

Ancak Scala’da aktörler dil düzeyinde değil, kütüphane düzeyinde desteklenir. Daha az bütünleştirilmiş olsa da, Actor kitaplığının evrimi dilin kendisini etkilemediğinden bu yaklaşım daha fazla esneklik de sağlar.

Scala tipik olarak JVM’nin üstünde oturduğundan, Scala aktörleri süreçlere değil, JVM iş parçacıklarına bağlıdır. Scala aktörlerinin ölçeklenebilirliğini anlamanın anahtarı, aktörler ve iş parçacıkları arasında bire bir ilişki olmadığını bilmektir. Örneğin, bir aktör bir mesaj beklerken, kilit bekleyen bir ileti dizisine de sahip olmayız. Bunun yerine, aktör gövdesi, hesaplamanın geri kalanını yakalayan bir kapatma tarafından taklit edilir.

Bu kapatma, bu aktörün tüketmesi için bir mesaj belirlenene kadar dahili olarak da önbelleğe alınır. Özellikle, Scala’nın Actor kitaplığı, işlenecek mesajların çok ince taneli seçimine izin vermek için eşleştirme yapısından da yararlanır. Bir başka ilginç not da, aktör gövdesinin (tepki işlevinin içindeki kısım) asla normal şekilde dönmemesidir; aslında, tepki fonksiyonunun dönüş tipi de söz konusudur.

Bu önemsiz örnekte, Ping, Pong ve Stop mesajlarını değiş tokuş eden iki aktörümüz var (mesajların model eşleştirme amaçları için vaka nesneleri olduğuna dikkat edin). Ayrıca hiçbir yerde açık bir şekilde thread kullanmadığımıza da dikkat edin. Ayrıca senkronize bloklar gibi herhangi bir iş parçacığı engelleme tekniği kullanmadık. Mecbur olmadığımız için de yapmadık. Aktörlerin mesaj iletme mekanizması genellikle güvenlidir.

İş parçacıklarının dahili olarak kullanıldığını ve bu özel örnekte yürütmenin aynı iş parçacığı üzerinde gerçekleşebileceğini unutmayın. Bunun nedeni, Actor kitaplığının dahili olarak bir iş parçacığı havuzu kullanması ve bir aktör bir mesaj aldığında yürütmenin iş parçacığı havuzundaki bir iş parçacığında da gerçekleşmesidir.

Küçük bir çalışan iş parçacığı havuzu kullanmak, aynı zamanda aktörlerin ölçeklenebilirliği için bir anahtardır: iş parçacıklarının çok verimli bir şekilde kullanılmasına ve aktör mesajı tüketir tüketmez havuza geri döndürülmesine de olanak tanır.

Eylemlerin ayrıntılarına inmek bu kapsamı dışındadır, ancak Scala oyuncularını tam olarak anlamak için diğer materyalleri okumanızı öneririz. Özellikle, oyuncularla ilgili makaleleri ve eğitimleri özetleyen güzel bir sayfası da var.

Web sitelerinizi, arama motorlarında en yukarı getirmek adına sizlere 3 adet paket öneriyoruz. Bu paketler sayesinde web siteleriniz aramalarda 1 yıl içerisinde en yukarıya tırmanacaktır. 

1) Backlink Paketi  50 $ (Yıllık Ücret)
2) Hızlandırma Paketi 300 $ (Yıllık Ücret)
3) Kelime Yönlendirme Paketi 150 $ (Aylık Ücret)

The post Web Kapsayıcısı – SEO Hizmeti Sunma – SEO Hizmeti – SEO Hizmeti Ücretleri – SEO Hizmeti Yaptırma first appeared on Jeff Bezos Tasarım.