Aşağıdaki seçeneklerden hangisi geçerli bir AppDomain nesnesi oluşturmak için doğru C# kodudur?
AppDomain d = new AppDomain(“Domain”, new Zone(SecurityZone.Internet));</pre>
AppDomain d = AppDomain.CreateDomain("Domain");AppDomain d = new AppDomain("Domain");object[] z = { new Zone(SecurityZone.Internet) };
Evidence e = new Evidence(z, null);
AppDomain d = new AppDomain("Domain", e);Sorunun doğru cevabı için;
Doğru cevap : 2. şık
AppDomain d = AppDomain.CreateDomain("Domain");
doğru cevap.
AppDomain nesnesinden yeni bir örnek oluşturmak için doğru yol, AppDomain class'ının static CreateDomain fonksiyonunu çağırmaktır.
AppDomain class'ı standart bir constructor'a sahip değildir.
Özellikle uygulama geliştiriciler için, kısa sınav formatında paylaşımlarım olacak.
Google, “Let’s make the web faster” vizyonu çerçevesinde pazara sürekli yeni ürünler/teknolojiler çıkartmaya devam ediyor.
Şuradan tamamını okuyabileceğiniz döküman ile HTTP protokolüne alternatif geliştirdiğini de öğrenmiş olduk.
Yeni protokole SPDY (SPeeDY şeklinde telaffuz ediliyor) ismini vermişler ve SSL üstünde çalışmasını sağlamışlar.
SPDY protokolünün tanımını yaptıkları dokümanda, HTTP’nin şu limitlerinden bahsediyorlar;
Bağlantı başına tek istek : HTTP, aynı anda tek kaynak talep edebilir, getirebilir. HTTP protokolü aynı anda tek istekte bulunabiliyor ve bu istekleri FIFO (First In, First Out) mantığı ile kuyruğa alıp işliyor.
Browser’lar bu problemi çözebilmek için, aynı anda 2 bağlantı açıyorlardı, 2008 yılından beri hemen hemen tüm browserlar, aynı anda bağlantı sayısını 6’ya çıkarttılar.
Sadece istemci istekte bulunabilir : HTTP protokolünde, sunucudan isteği sadece istemci yapabilir. Hatta sunucu, istemci’nin bir kaynağa ihtiyacı olduğunu bilse bile, istemci adına bu kaynağa erişip, sonucu istemciye döndüremez.
Request ve Response Header’larının sıkıştırılamaması : Günümüzde request header’larının boyutu, 200 bayt ile 2 kilobayt arasında değişiyor. Uygulamanızda cookie vs. kullanıyorsanız, boyut ortalama 700-800 bayt oluyor. Her isteğin (request) ve cevabın (response) headerında yer alan bilginin sıkıştırılmadan taşınması, önemli gecikmelere yol açmaktadır.
Gereksiz header bilgileri : Header’da hiç değişmeyecek bilgilerin (User-Agent, Host, Accept, … gibi) tekrar tekrar gönderilmesi gereksizdir. HTTP protokolü, bu bilgileri her isteğin ve cevabın headerına ekliyor.
Veri sıkıştırmasının varsayılan olmaması : HTTP protokolünde veri, varsayılan olarak sıkıştırılmamış formattadır. SPDY protokolünde Google, varsayılan olarak verinin tamamının sıkıştırılmış formatta olmasını sağlıyor.
Yapılan ölçümlemeye göre, sunucundan yapılan yükleme işlemlerinin %50 azalması iki kat hızlı sörf deneyimi sunacaktır. Birkaç yüz milisaniye, tek bir kullanıcı için çok önemli olmasa da, aynı anda yüzlerce, binlerce, hatta milyonlarca kullanıcıya hizmet veren web sunucular için çok önemlidir.
Google, SPDY protokolü ile tam olarak neyi hedefliyor?
HTTP GET ve HTTP POST komutlarının değişmeden kalması öngörülüyor, fakat SPDY ile yeni komutların da geleceği haber veriliyor.
Şu ana kadar Google, hafızada çalışan bir web sunucusu hazırlamış durumda, üstelik yakında açık kaynak olarak halka açmayı da planlıyor.
Chrome browser’ının da hem HTTP, hem de SPDY protokollerini destekleyen bir sürümünü (kod adı “flip”) çıkartmışlar, şuradan kaynak kodlarını indirebilirsiniz.
Bu prototipleri kullanarak yapılan testlerde ortaya çıkan sonuç;
“Top 100” listesinde yer alan 25 site, ev kullanıcısı bağlantı kapasitesini simule ederek, %1 paket kaybı ile 10’ar defa download edildi ve ortalamalar alındı.
SSL olmayan sitelerde hız artışı : %27 - %60 arasında,
SSL olan sitelerde hız artışı : %39 - %55 arasında.
Bu sonuçlara rağmen, Google’ın tek başına başarıyı yakalaması çok zor. Mutlaka sektör’deki diğer büyük firmalar’ın SPDY protokolünü desteklemesi lazım.
Sql Server 2008 ile birlikte gelen güzel bir yenilikten bahsetmek istiyorum, backup sırasında sıkıştırma (backup with compression)
Bu özelliği test etmek için, Sql Server 2008 R2 kurulu bilgisayarıma AdventureWorks 2008R2 veritabanını yükledim.
Yükleme işleminden hemen sonra, şu sql cümlesi ile veritabanının backup‘ını aldım;
Karşılaştırma yapabilmek ve COMPRESSION anahtar kelimesini denemek için, bir de şu sql cümlesi ile yedek aldım;
Gördüğünüz gibi, sıkıştırma özelliğini kullanmak için, backup script‘inin options parçasına (WITH anahtar kelimesinden sonra gelen kısım), COMPRESSION anahtar kelimesini eklemek yeterli.
Şimdi gelelim karşılaştırmalara;
Orjinal boyut : 200.192 KB (Data) + 38.912 KB (Log)
Backup işlemi (Normal) sonucu oluşan dosya : 186.461 KB
Backup işlemi (Compression) sonucu oluşan dosya : 44.507 KB
Normal backup’a göre sıkıştırma oranı : %77
Backup alma süreleri açısından karşılaştırma,
Backup işlemi (Normal) : 7.505 saniye (24.018 MB / saniye)
Backup işlemi (Compression) : 4.521 saniye (39.862 MB / saniye)
Hız artışı : %40
Ne yazık ki, CPU kullanım oranlarını ölçemedim. Eğer ölçebilen varsa, yorumlarınızı duymak isterim.
MSDN’de yeralan şu sayfada yazdığına göre, backup işlemine compression eklemek, CPU kullanımında önemli bir artışa yol açarmış.
Varsayılan olarak alınacak tüm backup’larda sıkıştırma özelliğini açmak istersek;
script‘ini çalıştırmak yeterli.
Pattern, kelime olarak fransızca patron kelimesinden gelmektedir ve tekrarlayan olayları veya nesneleri ifade etmektedir.
Yazılım dünyasında ise, “sürekli karşılaşılan durumlar için geliştirilmiş ve dökümante edilmiş, çözüm yolu standart haline gelmiş, tasarım kalıpları” şeklinde tanımlanabilir.
Senior Software Engineer, @Microsoft
Ada ve Ege'nin babası ;)
Makale Adedi: 484