Optimizasyon sistemi - tomcat parametre optimizasyonu (bellek, iş parçacığı, sıkıştırma, küme, ARP)
Genel Bakış
Tomcat optimizasyonunun içeriğiyle ilgili olarak, benim tarafım çoğunlukla bellek, iş parçacığı sayısı, açık sıkıştırma işlevi, küme ve ARP'den optimize eder. ARP burada nispeten nadiren kullanılmaktadır.
Optimizasyonla ilgili
1. Bellek optimizasyonu:
Yapılandırma dosyası: $ TOMCAT_HOME / bin / catalina.sh
dışa aktar JAVA_OPTS = "- sunucu -Xms1400M -Xmx1400M -Xss512k -XX: + AggressiveOpts -XX: + UseBiasedLocking -XX: PermSize = 128M -XX: MaxPermSize = 256M -XX: + DisableExplicitGC -XX: MaxTenuringThreshold = 31CM -XX: + UseParNewGC -XX: + CMSParallelRemarkEnabled -XX: + UseCMSCompactAtFullCollection -XX: LargePageSizeInBytes = 128m -XX: + UseFastAccessorMethods -XX: + UseCMSInitiatingOccupancyOnly -Djava.awt "Yukarıdaki konfigürasyon temelde şunları başarabilir:
Daha hızlı sistem yanıt süresi JVM kurtarma hızı, sistemin yanıt oranını etkilemeden artar JVM belleğinin maksimum kullanımı İş parçacığı engellemesini en aza indirinParametre açıklaması:
-server Tomcat sunucu modunda çalışır, daha büyük ve daha yüksek eşzamanlı işleme yeteneklerine sahip olacak, daha hızlı ve daha güçlü JVM çöp toplama mekanizmasına sahip olacak, daha fazla yük ve verim elde edebilecek, üretim ortamı eklenmelidir. -Xms -Xmx genellikle buradaki iki değeri eşit olarak ayarlar --Xmn genç nesil -Xss, her bir iş parçacığının yığın boyutunu, genellikle 128k veya 256k ayarlamayı ifade eder -XX: + AggressiveOpts Bu parametreyi etkinleştirin, ardından JDK sürümü her yükseltildiğinde, JVM'niz eklenen en son optimizasyon teknolojisini (varsa) kullanacaktır. -XX: + UseBiasedLocking, optimize edilmiş bir iş parçacığı kilidi sağlar, uygulama sunucumuzda her http isteğinin bir iş parçacığı olduğunu, bazı isteklerin kısa ve bazılarının uzun olduğunu, sıraya alınan isteklerin olacağını ve hatta iş parçacıkları görüneceğini biliyoruz Engelleme, bu optimize edilmiş iş parçacığı kilidi uygulama sunucunuzda iş parçacığı işlemenin otomatik olarak en iyi şekilde tahsis edilmesini sağlar. -XX: PermSize = 128M yığın olmayan başlangıç değeri -XX: MaxPermSize = 256M yığın olmayan maksimum -XX: + DisableExplicitGC Program kodu, "System.gc ()" için açık çağrılara izin vermiyor -XX: + UseParNewGC, koleksiyonun hızlı olması için genç nesil için çok iş parçacıklı paralel koleksiyon kullanır. -XX: + UseConcMarkSweepGC, CMS gc'dir. Sık sık GC'lerin JVM'de büyük iniş çıkışlara neden olacağını ve sistemin verimliliğini etkileyeceğini biliyoruz. Bu nedenle, CMS GC'yi kullandıktan sonra, GC'lerin sayısı arttığında her GC'nin yanıt süresi çok yüksektir. Kısa, örneğin, CMS GC'yi kullandıktan sonra, jprofiler'ın gözleminden sonra, GC birçok kez tetiklendi ve her GC yalnızca birkaç milisaniye sürdü. -XX: MaxTenuringThreshold, maksimum çöp yaşını ayarlar -XX: + CMSParallelRemarkEnabled UseParNewGC kullanılması durumunda, markalama süresini azaltmayı deneyin -XX: + UseCMSCompactAtFullCollection Eşzamanlı gc kullanılması durumunda, bellek parçalanmasını önleyin, canlı nesneleri düzenleyin ve bellek parçalanmasını azaltın -XX: + UseFastAccessorMethods get, yöntemi yerel koda ayarla -XX: LargePageSizeInBytes, Java yığınının sayfa boyutunu belirtir
2. Diş optimizasyonu ve sıkıştırmayı etkinleştirin
Yapılandırma dosyası: $ TOMCAT_HOME / conf / server.xml
Bu satırı bulun: < bağlayıcı bağlantı noktası = "8080" protokol = "HTTP / 1.1" >
URIEncoding = "UTF-8" minSpareThreads = "25" maxSpareThreads = "75" # enableLookups = "false" DNS sorgusunun performans üzerindeki etkisini ortadan kaldırmak için DNS sorgusunu kapatabiliriz enableLookups = "false" disableUploadTimeout = "true" connectionTimeout = "20000" #acceptCount, iş parçacığı sayısı maxThreads'e ulaştığında, sonraki istekler bir bekleme kuyruğuna konur, bu acceptCount bu kuyruğun boyutudur, bu kuyruk da doluysa, bağlantıyı doğrudan reddeder # maxProcessors = "2000" Genellikle 2000'e ayarlanır acceptCount = "300" maxThreads = "300" maxProcessors = "2000" minProcessors = "5" # Ek yükü azaltmak için bazı URL'lerdeki gereksiz kontrolleri azaltabilir. useURIValidationHack = "yanlış" #Configure Tomcat, gzip sıkıştırma (HTTP sıkıştırma) işlevi ile sıkıştırma = "üzerinde" sıkıştırmaMinSize = "2048" sıkıştırılabilirMimeType = "metin / html, metin / xml, metin / javascript, metin / css, metin / düz" redirectPort = "8443" / >Son olarak, 8443 numaralı bağlantı noktasının bu yapılandırmaya ayarlanması önerilir, çünkü https, 8443 numaralı bağlantı noktasını kullanır.
3. Kümeyi benimseyin
Nginx, istek şönt sunucusu olarak kullanılır ve arka uçtaki birden çok tomcats, birlikte çalışmak için oturumu paylaşır. Bu, temel olarak yük dengeleme ve dinamik ve statik ayırma için uygulanır.
Bu arada, şu iki kavramı tanıtın:
Yük dengeleme: Şu anda çoğu web sitesi, mevcut kullanıcıların üstel büyümesine göre tek noktalı sunuculardaki yük baskısını azaltmak için yük dengeleme yöntemlerini kullanıyor.Örneğin, şu anda 3 gerçek sunucumuz var. Hangi kullanıcı isteklerinin ilgili stratejilere göre tahsis edileceğine karar vermemiz gerekiyor. Hangi gerçek sunucu, örneğin, sorgulama yöntemine göre, kullanıcı istekleri vekil sunucuya teker teker ulaşır Bu anda vekil sunucu ilk isteği ilk gerçek sunucuya, ikinci isteği ikinci sunucuya vb. İletir. Bu, çok sayıda kullanıcının aynı fiziksel makineye tüm erişimi istemesini engelleyebilir.Tek noktalı bir fiziksel makinenin performansı her zaman sınırlıdır.Elbette bu, sunucu verilerine erişirken işlemsel hatalara neden olabilir ve Web'de Oturum erişim sorunlarına neden olabilir.
Dinamik ve statik kaynakların ayrılması: Listelemenin en uygun yolu, Java'nın JSP'si ile .js / .css / .html / .png gibi statik kaynakların ayrılmasıdır. Önceki web programlarında html, css ve diğer kaynak dosyaları da Tomcat'e yerleştirilmişti. Kullanıcı ziyaret ettikten sonra, tomcat'in istenen statik kaynak dosyalarını kullanıcıya iade etmesi gerekir.Aynı iş mantığına sahip birden çok tomcat sunucusu varsa, her sunucuya aynı kaynağın yerleştirilmesi gerekir ve bu da artar Tomcat sunucusunun ağ IO'su çok ekonomik değildir.Tomcat'e yalnızca JSP ve diğer istekler verilirse ve statik kaynaklar proxy sunucusunda depolanırsa, kullanıcı dinamik olmayan kaynaklar talep ettiğinde, proxy sunucusunun statik kaynaklarını tamamen aktarabiliriz Tomcat'in baskısını artırmadan doğrudan kullanıcıya geri dönün Tomcat'in yalnızca dinamik kaynakların mantıksal işlemesi ve yüklenmesinden sorumlu olması gerekir.
Küme mimarisi
4. Bunun yerine APR kitaplığını kullanın
Tomcat tarafından varsayılan olarak benimsenen BIO modeli, yüzlerce eşzamanlılık altında ciddi performans düşüşüne sahiptir. Tomcat bir NIO modeliyle birlikte gelir ve ayrıca işletim sistemi düzeyinde kontrol elde etmek için APR kitaplığını da arayabilirsiniz.
NIO modeli yerleşiktir ve çağrılması kolaydır.Yalnızca yukarıdaki yapılandırma dosyasındaki protokolü org.apache.coyote.http11.Http11NioProtocol olarak değiştirmeniz ve etkili olması için yeniden başlatmanız gerekir.
APR'nin, yüksek eşzamanlılık altında performansı önemli ölçüde artıracak üçüncü taraf kitaplıkları kurması gerekir.
Resmi karşılaştırma
Tomcat başladığında, Bağlayıcının hangi işletim modunu kullandığını günlük aracılığıyla görebilirsiniz:
- ProtocolHandler'ı başlatma
- ProtocolHandler'ı başlatma
- ProtocolHandler'ı başlatma
Önceki stres testinde, performans gerçekten de büyük ölçüde iyileştirildi Alan sınırlı, bu yüzden ARP'nin nasıl kurulacağını buraya tanıtmayacağım.
Bu temelde tomcat optimizasyonunun içeriğidir.Tomcat bir tıkanıklığa sahip olduğunda, bunu yapılandırmak için bu şablonu takip edebilirsiniz ve kesinlikle performans iyileştirmeleri olacaktır.
Devops ve DBA hakkında daha fazlasını daha sonra paylaşacağım ve ilgilenen arkadaşlar buna dikkat edebilir! !
