|
|
Yayınlandı 11.04.2018 17:33:18
|
|
|
|
Bu makalenin neyle ilgili olduğunu daha kolay anlamak için, Stack Overflow'un ortalama günlük istatistikindeki değişiklikle başlayalım. Aşağıdaki rakamlar 12 Kasım 2013 itibarıyla alınan istatistiklerden alınmıştır:
- Yük dengeleyici 148.084.833 HTTP isteği kabul etti
- Bunların 36.095.312'si sayfa yüklüydü
- 833.992.982.627 bayt (776 GB) HTTP trafiği gönderilmek için kullanılır
- Toplamda 286.574.644.032 bayt (267 GB) veri alındı
- Toplamda 1.125.992.557.312 bayt (1.048 GB) veri gönderildi
- 334,572,103 SQL sorgusu (yalnızca HTTP isteklerinden dahil)
- 412.865.051 Redis talebi
- 3.603.418 Tag Engine talebi
- SQL sorgularında 558,224,585 ms (155 saat) sürdü
- Redis talepleri için 99.346.916 ms (27 saat) sürdü
- Etiket motoru talebi için 132.384.059 ms (36 saat) harcadı
- ASP.Net işlem işlemi 2.728.177.045 ms (757 saat) sürdü
Aşağıdaki veriler, 9 Şubat 2016 itibarıyla istatistiklerdeki değişiklikleri göstermektedir, böylece karşılaştırabilirsiniz:
- Yük dengeleyici tarafından alınan HTTP istekleri: 209,420,973 (+61,336,090)
- 66.294.789 (+30.199.477) sayfa yükleniyor
- HTTP veri gönderildi: 1,240,266,346,053 (+406,273,363,426) bayt (1.24 TB)
- Alınan toplam veri miktarı: 569.449.470.023 (+282.874.825.991) bayt (569 GB)
- Gönderilen toplam veri miktarı: 3.084.303.599.266 (+1.958.311.041.954) bayt (3,08 TB)
- SQL sorguları (sadece HTTP isteklerinden): 504,816,843 (+170,244,740)
- Redis Cache İzlenme Sayıları: 5.831.683.114 (+5.418.818.063)
- Elastik Aramalar: 17.158.874 (2013'te takip edilmedi)
- Etiket Motoru İstekleri: 3.661.134 (+57.716)
- SQL sorgularını çalıştırmak için kullanılan kümülatif süre: 607,073,066 (+48,848,481) ms (168 saat)
- Redis önbellek kullanım süresi: 10.396.073 (-88.950.843) ms (2.8 saat)
- Etiket Motoru İstekleri Tarafından Tüketilen Süre: 147.018.571 (+14.634.512) ms (40.8 saat)
- ASP.Net İşlemde Tüketilen Süre: 1.609.944.301 (-1.118.232.744) ms (447 saat)
- 22.71 (-5.29) ms 49.180.275 sayı sayfa ortalama render süresi (bunun 19.12 ms ASP.Net içinde tüketilir)
- 11.80 (-53.2) ms 6.370.076 ilk sayfa ortalama render süresi (bunun 8.81 ms ASP.Net içinde tüketilir)
ASP.Net'nin günde 61 milyon daha fazla talep işliyor ama işlem süresini 2013'e göre 757 saat azalttığını merak ediyor olabilirsiniz. Bunun başlıca nedeni, 2015 başında sunucularımızda yaptığımız yükseltmeler ve uygulama içi performans optimizasyonu çalışmalarından kaynaklanıyor. Unutmayın: performans hâlâ bir satış noktası. Eğer donanım detaylarını daha çok merak ediyorsanız, endişelenmeyin, bu siteleri çalıştırmak için kullanılan sunucuların donanım detaylarını bir sonraki makalede ek olarak vereceğim (zamanı geldiğinde bu bağlantıyı güncelleyeceğim).
Peki son iki yılda neler değişti? Çok fazla bir şey yok, sadece bazı sunucuları ve ağ ekipmanlarını değiştirdim. İşte bugün web sitenizi çalıştırmak için kullanılan sunucuların genel bir özeti (2013'ten beri nasıl değiştiğine dikkat edin)
- 4 Microsoft SQL Server sunucusu (bunlardan 2'si yeni donanım kullanıyor)
- 11 IIS Web Sunucusu (Yeni Donanım)
- 2 Redis sunucusu (yeni donanım)
- 3 Tag Engine sunucusu (bunlardan 2'si yeni donanım kullanıyor)
- 3 Elasticsearch sunucusu (yukarıdakilerle aynı)
- 4 HAProxy yük dengeleme sunucusu (CloudFlare desteklemek için 2 tane eklendi)
- 2 ağ cihazı (Nexus 5596 çekirdek + 2232TM Fabric Extender, tüm cihazlar 10Gbps bant genişliğine yükseltilmiş)
- 2 x Fortinet 800C Firewall (Cisco 5525-X ASA'larının yerini alır)
- 2 Cisco ASR-1001 yönlendirici (Cisco 3945 yönlendiricilerinin yerini alır)
- 2 Cisco ASR-1001-x Yönlendirici (YENİ!) ）
Stack Overflow'un çalışması için neye ihtiyacımız var? 2013'ten bu yana pek bir şey değişmedi, ancak yukarıda bahsedilen optimizasyonlar ve yeni donanım sayesinde artık sadece bir web sunucusuna sahibiz. Bu durumu istemeden de olsa birkaç kez başarılı bir şekilde test ettik. Lütfen not edin: Az önce işe yaradığını söyledim, iyi bir fikir demedim. Ama her böyle olduğunda oldukça ilginç oluyor.
Sunucu ölçeklendirme fikirleriyle ilgili bazı temel rakamlara sahip olduğumuza göre, bu harika web sayfalarını nasıl yaptığımıza bakalım. Çok az sistem tamamen bağımsız olarak var olur (bizimki de istisna değildir) ve bu parçaları bütünsel bir bakış açısı olmadan mimari planlamanın anlamı büyük ölçüde azalır. Amacımız genel durumu kavramak. Gelecekte her belirli alana derinlemesine innen birçok makale olacak. Bu makale, anahtar donanımın mantıksal yapısının sadece bir özetidir ve bir sonraki makale bu donanımlar hakkında özel detaylar içerecektir.
Bu donanımın bugün nasıl göründüğünü görmek isterseniz, Şubat 2015'te sunucuyu güncellerken Cabinet A'nın (Cabinet B tam olarak aynı) çektiğim birkaç fotoğraf işte:
Şimdi, mimari düzene dalalım. Aşağıda, mevcut ana sistemlerin mantıksal mimarisinin özeti verilmiştir:
Temel prensipler
İşte sırayla tanıtılması gerekmeyen bazı yaygın ilkeler:
- Her şeyin yedek yedeklemeleri var.
- Tüm sunucular ve ağ cihazlarının en az iki adet 10Gbps bant genişliği bağlantısı vardır.
- Tüm sunucularda iki güç kaynağı bulunur ve bu kaynaklar iki UPS ünite seti, arkasında iki jeneratör ve iki şebeke gerilim beslemesi ile güç sağlar.
- Tüm sunucuların Rack A ve Rack B'de bulunan yedek yedek bir yedek bulunur.
- Tüm sunucular ve hizmetler ayrı bir veri merkezinde (Colorado'da) çift yedek yedeklemeye sahip, ancak ben ağırlıklı olarak New York'u kapsayıyorum.
- Her şeyin yedek yedeklemeleri var.
Internet
Önce web sitemizi bulmanız gerekiyor, ki bu DNS ile ilgili. Web sitelerini bulmak hızlı, bu yüzden şimdi CloudFlare'e veriyoruz çünkü dünyanın her köşesinde DNS sunucuları var. DNS kayıtlarını API'ler aracılığıyla güncelliyoruz ve DNS'i "yönetmekten" sorumlu olanlar. Ancak, kötü niyetli zihnimizde, derin köklü güven sorunları nedeniyle hâlâ kendi DNS sunucularımız var. Kıyamet kıyamet gibi olduğunda – belki GPL, Punyon veya önbellek sorunları nedeniyle – ve insanlar hâlâ dikkatlerini yayındırmak için programlamak istediğinde, kendi DNS sunucularımıza geçiyoruz.
Tarayıcınız saklanma yerimizi bulduğunda, dört ISS'mizden (Level 3, Zayo, Cogent ve New York'taki Lightower) gelen HTTP trafiği dört gelişmiş yönlendiricimizden birine giriyor. Ağ sağlayıcılarından gelen eşler arası trafiği kontrol etmek ve hizmetlerimize en verimli erişim sağlamak için Border Gateway Protocol (BGP, çok standart bir protokol) kullanıyoruz. ASR-1001 ve ASR-1001-X yönlendiricileri iki gruba ayrılmıştır; her biri her iki ağ sağlayıcısından gelen trafiği yönetmek için aktif/aktif mod kullanmalı – burada yedek yedeklemeler vardır. Hepsinin fiziksel bant genişliği 10Gbps olmasına rağmen, dışarıdan gelen trafik harici VLAN'dan bağımsızdır ve yük dengeleyiciye ayrı ayrı bağlıdır. Trafik yönlendiriciden geçtikten sonra yük dengeleyiciye geleceksiniz.
İki veri merkezi arasında 10Gbps bant genişliğine sahip MPLS olduğunu belirtmenin zamanı gelmiş olabilir, ancak bu doğrudan web sitesi hizmetleriyle ilgili değil. Bu teknolojiyi, belirli acil durumlarla başa çıkmak için saha dışı çoğaltma ve hızlı veri kurtarma gerçekleştirmek için kullanıyoruz. "Ama Nick, bunda bir gereksiz yok!" Teknik açıdan (olumlu anlamda) haklısınız, bu seviyede gerçekten tek bir başarısızlık noktası. Ama bekle! Ağ sağlayıcısı aracılığıyla ayrıca iki ek OSPF failover rotası da var (MPLS birinci tercih, bunlar maliyet nedeniyle ikinci ve üçüncü seçenekler). Daha önce bahsedilen cihaz setlerinin her biri, bir devre durumunda yük dengesi ağ trafiğine uygun olarak Colorado'nun veri merkezine bağlanacaktır. Tabii ki, bu iki cihaz setini birbirine bağlayabilirdik, böylece dört yol seti olurdu, ama boşver, devam edelim.
Yük Dengeleme (HAProxy)
Yük dengeleme, CentOS 7 (Linux'un favori sürümümüz) üzerinde çalışan HAProxy 1.5.15 ile uygulanıyor. Ve HAProxy'ye TLS (SSL) güvenli iletim protokolü ekleyin. Ayrıca HTTP/2 protokolünü hemen destekleyecek olan HAProxy 1.7'yi de takip ediyoruz.
Çift 10Gbps LACP ağ bağlantısına sahip diğer sunucuların aksine, her yük dengeleyicinin iki adet 10Gbps bağlantısı vardır: biri harici ağ için, diğeri DMZ için. Bu sunucular, SSL protokol katmanını daha verimli işlemek için 64GB veya daha fazla belleğe sahiptir. Daha fazla TLS oturumunu bellekte önbelleyip yeniden kullanabildiğimizde, aynı istemciye bağlanırken daha az hesaplama kaynağı tüketiriz. Bu da seansları daha hızlı ve daha ucuz bir şekilde restore edebildiğimiz anlamına geliyor. Hafıza o kadar ucuz ki kolay bir seçim.
Yük dengelemesi kendisi kolayca kurulabilir. Farklı web sitelerini birden fazla farklı IP'de dinliyoruz (çoğunlukla sertifika ve DNS yönetimi nedeniyle) ve ardından trafiği farklı arka uçlara yönlendiriyoruz (çoğunlukla ana bilgisayar başlıklarına dayanarak). Burada yaptığımız tek şey, hızı sınırlamak ve web katmanından bazı başlık bilgilerini kazıyarak HAProxy'nin sistem log mesajlarına giriş yapmaktır; böylece her istek için performans metriklerini kaydedebiliriz. Bunu daha sonra detaylı olarak anlatacağız.
Web katmanı (IIS 8.5, ASP.Net MVC 5.2.3 ve .Net 4.6.1)
Yük dengeleme, trafiği ana web sunucusu olarak adlandırdığımız 9 sunucu (01-09) ile 2 geliştirme web sunucusu (10-11, test ortamımız) arasında dağıtır. Ana sunucu Stack Overflow, Careers ve tüm Stack Exchange sitelerini çalıştırırken, meta.stackoverflow.com ve meta.stackexchange.com iki başka sunucuda çalışıyor. Ana Soru-Cevap uygulaması çoklu kiracı olduğundan, tek bir uygulama Soru-Cevap sitesinden gelen tüm talepleri yönetir. Başka bir deyişle, tüm Soru-Cevap uygulamasını tek bir uygulama havuzunda ve tek bir sunucuda çalıştırabiliriz. Careers, API v2, Mobile API gibi diğer uygulamalar bağımsızdır. İşte IIS'de ana ve geliştirici sunucular için gördükler:
İşte Stack Overflow'un web katmanının Opserver'da (dahili izleme panelimiz) görülen dağılımı şöyle:
Ve işte bu web sunucularının kaynak tüketimi:
Neden bu kadar fazla kaynak sunduğumuzu daha ayrıntılı bir makalede anlatacağım; odaklanarak rolling build, esneklik ve yedekliliğe odaklanıyorum.
Hizmet katmanı (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 ve HTTP. SYS)
Web katmanının yanında servis katmanı bulunur. Ayrıca Windows 8.5R2 ile IIS 2012'nin üzerinde çalışıyorlar. Bu katman, web katmanını ve üretim ortamının diğer dahili sistemlerini destekleyen bazı dahili servisleri çalıştırır. İki ana hizmet şunlardır: "Stack Server", bir etiket motoru çalıştırır ve http.sys (IIS değil); Providence API'si (IIS temelli). İlginç bir gerçek: Stack Server, sorun listesini iki dakikalık aralıklarla yenilerken L2 ve L3 önbelleklerine çok sık erişerek farklı soketlere bağlanmak için iki süreci ilişkilendirmek zorunda kaldım.
Bu hizmetleri çalıştıran makineler, etiket motoru ve arka uç API'leri için kritiktir, bu yüzden yedekli olmalılar, ancak 9x fazladan değiller. Örneğin, veritabanından her n dakikada bir (şu anda 2 dakika) tüm makaleleri ve etiketlerini yüklüyoruz, bu da düşük değil. Bu yükleme işlemini web katmanında 9 kez tekrarlamak istemiyoruz, 3 kez bizim için yeterince güvenli. Ayrıca, etiket motoru ve elastik indeks işlerinin (bu katmanda da çalışan) hesaplama ve veri yükleme özelliklerini daha iyi optimize etmek amacıyla bu sunucular için farklı donanım yapılandırmaları kullanıyoruz. "Etiket motoru" kendisi nispeten karmaşık bir konu ve özel bir makalede ele alınacak. Temel ilke, adres/questions/tagged/java'ya eriştiğinizde, etiketleme motoruna gidip ona uygun soruları alırsınız. Motor, /search hariç tüm etiket eşleştirmelerini yönetiyor, yani yeni navigasyon da dahil her yerde veri bu hizmet üzerinden alıyor.
Önbellek Oluşturma ve Yayıncılık/Abonelik (Redis)
Bazı yerlerde Redis kullandık ve sağlam bir stabilitesi var. Ayda 160 milyara kadar işlem olmasına rağmen, bir örnek başına CPU %2'yi aşmaz, bu genellikle daha düşüktür:
L1/L2 seviyesinde önbellek sistemleri için Redis kullanıyoruz. "L1" seviyesi, web sunucusunda veya benzeri herhangi bir uygulamada çalışan HTTP önbellektir. "L2" seviyesi, önceki seviye önbellek arızalandıktan sonra Redis üzerinden veri elde etmektir. Verilerimiz, Marc Gravel tarafından yazılmış protobuf-dot-net üzerinden uygulanan Protobuf formatında saklanıyor. Redis istemcisi için, kendi içinde geliştirilen açık kaynaklı bir kütüphane olan StackExchange.Redis kütüphanesini kullandık. Bir web sunucusu hem L1 hem de L2 önbelleğine ulaşmazsa, veri kaynaklarından (veritabanı sorguları, API çağrıları vb.) veri alır ve sonuçları yerel önbelleğe ve Redis'e kaydeder. Aynı veri alınırken bir sonraki sunucu L1 önbelleğinden eksik olabilir, ancak veri L2/Redis'te alır ve veritabanı sorguları veya API çağrıları gerekmez.
Ayrıca birçok Soru-Cevap sitesi çalıştırıyoruz, her birinin kendi L1/L2 önbelleği var: anahtar ön ek olarak L1 önbellekte ve veritabanı kimliği L2/Redis önbelleğinde. Bu konuya gelecekteki makalelerde değineceğiz.
Tüm site örneklerini çalıştıran iki ana Redis sunucusuna (biri ana ve bir slave) ek olarak, iki ayrı köle sunucu kullanarak makine öğrenimi için (çoğunlukla bellek nedenleriyle) bir örnek de kurduk. Bu sunucu grubu, ana sayfada sorular önermek ve iş eşleştirmelerini daha iyi yapmak gibi hizmetler sunmak için kullanılır. Bu platformun adı Providence ve Kevin Montrose bu konuda yazdı.
Ana Redis sunucusunda 256GB RAM (yaklaşık 90GB kullanılmış) varken, Providence sunucusunda 384GB bellek (yaklaşık 125GB kullanılmıştır).
Redis sadece önbellek için değil, aynı zamanda bir sunucunun mesaj yayınlayabileceği ve diğer abonelerin mesajı alabileceği bir yayınlama ve abonelik mekanizması da vardır (sunucudaki aşağı akış istemcilerinden gelen Redis dahil). Bu mekanizmayı diğer servislerde L1 önbelleği temizlemek için kullanıyoruz, böylece web sunucusunda önbellek tutarlılığını koruyoruz. Ama başka önemli bir kullanımı daha var: web soketleri.
Websockets (NetGain)
Websocket'leri kullanarak kullanıcılara gerçek zamanlı güncellemeler gönderiyoruz; örneğin üst çubuktaki bildirimler, oylar, yeni gezinme, yeni cevaplar, yorumlar ve daha fazlası.
Soket sunucusu kendisi web katmanında çalışır ve yerel soketler kullanır. Bu, açık kaynak kütüphane uygulamamıza dayanan çok küçük bir uygulamadır: StackExchange.NetGain. Yoğun saatlerde yaklaşık 500.000 eşzamanlı websocket bağlantımız vardı, bu da çok sayıda tarayıcı demek. Eğlenceli bilgi: bu tarayıcıların bazıları 18 aydan fazla süredir açık ve bu geliştiricilerin hâlâ hayatta olup olmadığını görmek için birini bulmanız gerekecek. Aşağıdaki grafik, bu hafta websocket eşzamanlılığının desenini göstermektedir:
Neden websocket kullanıyorum? Bizim ölçekimizde, anketlerden çok daha verimli. Bu şekilde, daha az kaynakla daha fazla veri gönderebilir ve kullanıcılar için daha gerçek zamanlı olabiliriz. Bu yaklaşım sorunsuz değil: geçici portlar, yük dengeleyicilerdeki tükenmiş dosya tutacakları çok ilginç sorunlar ve bunları daha sonra konuşacağız.
Arama (Elasticsearch)
Spoiler: Burada heyecanlanacak pek bir şey yok. Web katmanı Elasticsearch 1.4 kullanır ve ultra hafif, yüksek performanslı bir StackExchange.Elastic istemcisi uygular. Çoğu şeyin aksine, bu kısmı açık kaynak olarak kullanmayı planlamıyoruz, çünkü kullanmamız gereken API'lerin çok küçük bir alt kümesini açığa çıkarıyor. Bunu kamuya açıklamak, kaybı daha ağır basar ve geliştiricileri sadece şaşırtırır. Bu yerlerde ilgili soruları hesaplamak ve soru sorarken öneriler vermek için elastik:/search kullanıyoruz.
Her Elastik küme (her veri merkezi için bir tane) 3 düğüm içerir ve her biri kendi indeksine sahiptir. Kariyer sitesinde ayrıca bazı ek indeksler de bulunmaktadır. Elastik dairelerdeki yapılandırmamızın biraz daha az standart bir kısmı, 3 sunuculuk kümemizin normal yapılandırmadan biraz daha güçlü olmasıdır: her sunucu SSD depolama, 192GB bellek ve 10Gbps bant genişliğinde çift ağ kullanıyor.
Stack Server'ın aynı uygulama alanı (evet, burada .Net Core tarafından dolaştık) aynı zamanda sürekli indeksleme için Elasticsearch kullanan bir etiket motoru da barındırıyor. Burada küçük bir hile kullanıyoruz; örneğin SQL Server'da (veri kaynağı) ROWVERSION kullanarak Elastic'teki "son yer" belgesiyle karşılaştırıyoruz. Görünüşe göre ardışık olduğu için, son ziyaretten sonra içerik değiştirilirse kolayca taramak ve indekslemek mümkün oluyor.
SQL tam metin arama gibi teknolojiler yerine Elasticsearch kullanmamızın ana nedeni, ölçeklenebilirliği ve maliyet etkinliğidir. SQL CPU'larda nispeten pahalı, Elastic ise çok daha ucuz ve son zamanlarda birçok yeni özellik sunuyor. Neden Solr kullanmıyorsun? Ağ boyunca (aynı anda birden fazla indeksle) arama yapmamız gerekiyor ve Solr karar verdiğimiz anda bu senaryoyu desteklemiyor. 2.x'i henüz kullanmamamızın sebebi, 2.x'te türlerin çok değişmiş olması, yani yükseltmek istiyorsak her şeyi yeniden indekslememiz gerekiyor. Gereksinim değişiklikleri ve geçişler için planlama yapacak yeterli zamanım yok.
Database (SQL Server)
SQL Server'ı tek bir gerçek kaynağı olarak kullanıyoruz. Elastic ve Redis'teki tüm veriler SQL Server'dan gelir. İki SQL Server kümemiz var ve AlwaysOn erişilebilirlik gruplarıyla yapılandırıldık. Her kümenin New York'ta bir ana sunucusu (neredeyse tüm yükü üstlenen) ve bir replika sunucusu, ayrıca Colorado'da (felaket kurtarma veri merkezimiz) bir replika sunucusu vardır. Tüm kopyalama işlemleri asenkrondur.
İlk küme, her biri 384GB belleğe sahip, 4TB alana sahip bir PCIe SSD ve iki 12 çekirdekli CPU'ya sahip bir dizi Dell R720xd sunucusudur. Stack Overflow, Sites (kötü bir isim, sonra açıklayacağım), PRIZM ve Mobile'ın veritabanını içeriyor.
İkinci küme, her biri 768GB belleğe sahip, 6TB alana sahip bir PCIe SSD ve iki 8 çekirdekli CPU'ya sahip Dell R730xd sunucularından oluşmaktadır. Bu küme, Kariyerler, Açık ID, Sohbet, istisna kayıtları ve diğer Soru-Cevap siteleri (örneğin, Süper Kullanıcı, Sunucu Hatası vb.) dahil olmak üzere tüm diğer veritabanlarını içerir.
Veritabanı katmanında, CPU kullanımını çok düşük seviyede tutmak istiyoruz, ancak pratikte planlanan önbellek sorunları ortaya çıktığında (ki bunları sorun gideriyoruz) CPU kullanımı biraz daha yüksek olacak. Şu anda NY-SQL02 ve 04 ana sunucular, 01 ve 03 ise replika sunucular ve bugün SSD yükseltmesi nedeniyle onları yeniden başlattık. İşte son 24 saatte nasıl performans gösterdikleri:
SQL kullanımımız çok basit. Basit demek hızlı. Bazı sorgu ifadeleri saptırılabilir olsa da, SQL ile etkileşimimiz oldukça doğal bir şekilde gerçekleşir. Bazı eski Linq2Sql'lerimiz var, ancak tüm yeni geliştirmelerimiz POCO kullanan açık kaynaklı mikro-ORM çerçevemiz Dapper'ı kullanıyor. Başka bir şekilde açıklayayım: Stack Overflow'un veritabanında sadece bir seyrede saklanan prosedür var ve bu kalan son depolanmış prosedürü kapatıp yerine kod koyacağım.
Kütüphane
Şimdi fikrimizi değiştirelim, işte sana daha doğrudan yardımcı olabilecek şeyler. Bazılarını daha önce de bahsetmiştim, ama size sahip olduğumuz ve herkesin kullandığı birçok açık kaynaklı .Net kütüphanesinin bir listesini vereceğim. Onları açık kaynak olarak kullanıyoruz çünkü temel iş değerleri yok, ama dünya çapındaki geliştiricilere yardımcı olabiliyorlar. Umarım şimdi kullanabilirsin:
- Dapper (.Net Core) – ADO.Net için yüksek performanslı bir mikro-ORM çerçevesi
- StackExchange.Redis – Yüksek performanslı bir Redis istemcisi
- MiniProfiler – her sayfada kullandığımız hafif bir profil cihazı (ayrıca Ruby, Go ve Node'u da destekliyor)
- Exceptional – SQL, JSON, MySQL vb. dillerinde hata kaydetme için
- Jil – Yüksek performanslı JSON serileştirme ve deserileştirici
- Sigil – .Net CIL Generation Helper (C# yeterince hızlı olmadığında kullanılır)
- NetGain – Yüksek performanslı websocket sunucusu
- Opserver – Çoğu sistemi doğrudan soran ve Orion, Bosun veya WMI'dan bilgi alabilen izleme paneli
- Bosun – Arka planda izleme sistemi, Go ile yazılmış
|
Önceki:enum enum, bir değerin enum'a dahil olup olmadığını kontrol ederÖnümüzdeki:MB'yi nasıl hızlıca bulabilirim?
|
