Benchmark Sonuçları - Apinizer Dokümantasyonu

Özet

Eş-Zamanlı 2.000 Thread ile 1 CPU 8 Core sistem üzerinde, 15.000 reqs/sec karşılanmaktadır.

Bu sonuçlar çağrılan servisin yanıt süresine, network gecikmesine, gateway üzerine eklenen politikaların sistem gereksinimlerine göre değişiklik göstereceğinden yaptığımız yük testinin detaylarını aşağıdaki bölümde inceleyebilirsiniz.

Test Ortamı

Apinizer platformunun kolay kullanımı ve hızlı desteği nedeniyle yük testlerinin çalıştırılmasında altyapı olarak DigitalOcean platformu kullanılmıştır.

Yük Testi Topolojisi

Yük testi topolojisi aşağıdaki gibidir:

Yük Test Sunucusu

CPU-Optimized
Dedicated CPU
8 vCPUs (Intel Xeon Scalable, 2.5 GHz)
16 GB RAM
100 GB Disk
CentOS 8.3 x64

Kubernetes Master & MongoDB

CPU-Optimized
Dedicated CPU
4 vCPUs (Intel Xeon Scalable, 2.5 GHz)
8 GB RAM
50 GB Disk
CentOS 8.3 x64

Elasticsearch

CPU-Optimized
Dedicated CPU
8 vCPUs (Intel Xeon Scalable, 2.5 GHz)
16 GB RAM
100 GB Disk
CentOS 8.3 x64

Kubernetes Worker

CPU-Optimized
Dedicated CPU
16 vCPUs (Intel Xeon Scalable, 2.5 GHz)
32 GB RAM
200 GB Disk
CentOS 8.3 x64

Test Kurulumu

1. Yük Test Sunucusu Kurulumu ve JMeter Yapılandırması

Yük testi için JMeter kullanılmıştır. Kurulum adımları:

Java Kurulumu

yum install java-1.8.0-openjdk -y
java -version

Kurulum Doğrulama:

openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)

JMeter Kurulumu

yum install wget -y
wget http://apache.stu.edu.tw//jmeter/binaries/apache-jmeter-5.2.1.tgz
tar -xf apache-jmeter-5.2.1.tgz

Ortam Değişkenleri:

export JMETER_HOME=/root/apache-jmeter-5.2.1
export PATH=$JMETER_HOME/bin:$PATH
source ~/.bashrc

Test Senaryosu Yapılandırması

Thread sayısı parametrik yapılandırıldı
Test süresi parametrik yapılandırıldı
HTTP istekleri yapılandırıldı
Sonuç toplama mekanizması ayarlandı

2. NGINX Yapılandırması

NGINX, yük dengeleyici olarak kullanılmıştır:

NGINX Özellikleri

Load balancing
SSL termination
Reverse proxy
Health check

Yapılandırma

Upstream server tanımları
Proxy pass ayarları
Timeout ayarları
Connection pool ayarları

3. Apinizer ve Log Server Kurulumu

Kubernetes, MongoDB ve Elasticsearch kurulumları Apinizer kurulum dokümantasyonuna göre yapılmıştır.

Kubernetes master, worker, MongoDB, Elasticsearch ve Apinizer kurulumları Apinizer Kurulum Dokümantasyonu adresinde yer alan kurulum adımları takip edilerek yapılmıştır.

Yük Testinin Önemli Noktaları

Test ederken dikkat edilecek noktalar:

Asenkron Loglama

Apinizer, tüm istek & yanıt mesajlarını ve metriklerini Elasticsearch log veritabanında asenkron olarak saklar. Testler sırasında bu loglama işlemleri olması gerektiği gibi devam etti.

Ağ Gecikmesi

Tüm testlerimizde ağ gecikmesini azaltmak ve Apinizer’ın gerçek etkisini görmek için iç IP’ler kullanıldı.

Pod Yeniden Başlatma

Kubernetes’in çalışma zamanı sırasında pod’ları yeniden başlatmadığını özellikle gözlemledik. Yeniden başlatma sayısı, aşırı yük/tıkanma veya hatalı durumları yansıttığı için önemli bir parametredir.

JVM Monitoring

JVM performans metrikleri JConsole ile izlendi. JMX servisi Kubernetes üzerinden dış dünyaya açıldı.

Test Senaryoları

Test senaryoları farklı durumlar için yapılandırılmıştır:

Durum A - Temel Konfigürasyon

Minimal konfigürasyon
Temel API Proxy
Politikasız test

Durum B - Orta Seviye Konfigürasyon

Orta seviye konfigürasyon
Temel politikalar
Standart kullanım senaryosu

Durum C - Gelişmiş Konfigürasyon

Gelişmiş konfigürasyon
Çoklu politika desteği
Yüksek performans senaryosu

Durum D - Optimize Edilmiş Konfigürasyon

Optimize edilmiş konfigürasyon
Performans optimizasyonları
Production-ready senaryo

Yük Testi Sonuçları

GET İstekleri Sonuçları

Durum	Thread Count	Throughput (reqs/sec)	Avg Response Time (ms)
A	50	1,133	43
	100	1,100	90
	250	1,025	242
	500	963	516
B	50	2,232	22
	100	2,169	45
	250	2,089	119
	500	1,915	259
	1,000	1,762	564
	1,500	1,631	915
	2,000	1,379	1,441
C	50	8,090	6
	100	7,816	12
	250	7,011	35
	500	6,759	73
	1,000	6,742	147
	1,500	6,683	223
	2,000	6,692	297
	4,000	6,448	617
D	50	15,420	3
	100	15,812	6
	250	15,614	15
	500	15,664	31
	1,000	15,454	64
	1,500	15,026	99
	2,000	14,839	133
	4,000	14,356	276
	8,000	11,603	655

POST 5KB İstekleri Sonuçları

Durum	Thread Count	Throughput (reqs/sec)	Avg Response Time (ms)
A	50	1,002	49
	100	983	101
	250	852	292
B	50	1,868	26
	100	1,768	56
	250	1,456	170
	500	1,398	355
	1,000	1,229	809
	1,500	1,199	1,245
C	50	7,353	6
	100	7,257	13
	250	7,138	34
	500	7,141	69
	1,000	7,011	141
	1,500	6,935	215
D	50	13,396	3
	100	13,482	7
	250	13,587	18
	500	13,611	36
	1,000	13,562	73
	1,500	13,208	112
	2,000	13,179	150
	4,000	12,792	309
	8,000	11,115	701

POST 50KB İstekleri Sonuçları

Durum	Thread Count	Throughput (reqs/sec)	Avg Response Time (ms)
A	50	675	73
	100	653	152
	250	554	448
B	50	1,437	34
	100	1,409	70
	250	1,223	203
	500	1,149	432
	1,000	877	1,134
C	50	4,679	10
	100	4,675	21
	250	4,020	61
	500	3,221	154
	1,000	2,962	335
D	50	4,683	10
	100	4,671	21
	250	4,382	56
	500	3,496	142
	1,000	3,046	326
	1,500	2,853	522
	2,000	2,794	710

Sonuçların Yorumlanması

Eş Zamanlı Kullanıcı ve İstek Sayısı

Önemli: Sonuçları incelerken çok sık yapılan hata session sayısı ile anlık istek sayısının karıştırılmasıdır.

Throughput & Concurrent Users:

Throughput ve Eş Zamanlı Kullanıcı Sayısı

Ortalama Bellek Kullanımı:

İstek

Belirli bir HTTP metodu ile belirli bir hedef için yapılan HTTP isteğidir

Session

Session başına sıfır veya daha fazla istek olabilir

Gateway’lerde session tutmak çok nadir görülür, genellikle servislere erişim stateless’dir. Bu yüzden eş zamanlı istek sayısını ve gecikmeyi (latency) ölçmek daha anlamlı hale gelir.

Ölçeklendirme

Dikey Ölçeklendirme

Eşzamanlı kullanıcı sayısı arttığında verim belirli bir sınıra kadar artar. Sonrasında düşüş yaşanmaya başlar. Bu doğal seyir dikey büyümenin bir sınırı olduğunu ifade eder.

Yatay Ölçeklendirme

Kabul edilebilir yanıt sürelerine sahip daha fazla eşzamanlı kullanıcıyı desteklemek için yatay veya dikey ölçeklendirmeyi beraber düşünmek gerekir. Apinizer’da Kubernetes altyapısı kullanıldığından bu işlem çok kolay ve hızlı şekilde yapılandırılabilir.

Mesaj Boyutu Etkisi

Mesaj boyutları arttığında işlem gücü artacağından verim azalır. Dolayısıyla yanıt süresi de uzar.

GET vs POST 5KB

Genellikle gerçek yaşam senaryolarında istek boyutları 1KB ortalamasında olsa da testlerimizde 1KB POST ile GET isteklerimiz arasında çok küçük bir fark olduğundan 5KB ve 50KB POST isteklerini incelemeye değer bulduk.

POST 5KB vs POST 50KB

Sonuçlar doğal olarak GET isteklerine göre daha düşük bir değerde seyretse de 10 kat artan veriye göre rakamların sadece 4’te birine düşmesi bizim adımıza sevindirici oldu.

Bellek Kullanımı

Yük testi boyunca harcanan RAM oranları çok tutarlıydı. İsteklerin boyutu on kat artsa da RAM kullanımında ciddi bir artış gözlenmedi. Bu da OpenJ9’un doğru bir tercih olduğunu ispatladı.

Politika Performans Etkisi

Gateway’e eklediğimiz her bir politika, gateway’de karmaşıklığına ve bağımlılıklarına göre performansı etkiler.

Basic Authentication Politika Testi

“Basic Authentication” politikası eklenerek test edilmiştir (Durum D):

Thread Count	GET Throughput	GET Avg (ms)	GET with Policy Throughput	GET with Policy Avg (ms)
50	15,420	3	14,760	3
100	15,812	6	14,843	6
250	15,614	15	14,891	16
500	15,664	31	14,748	33
1,000	15,454	64	14,285	68
1,500	15,026	99	14,373	102
2,000	14,839	133	14,280	136
4,000	14,356	276	13,795	279
8,000	11,603	655	11,437	672

Throughput & Concurrent Users:

Throughput Karşılaştırması - Politika ile ve Politika Olmadan

Ortalama Bellek Kullanımı:

Gördüğümüz gibi performansa etkisi hissedilmeyecek derecede de olsa olmuş. Fakat örneğin “content filtering” gibi işlem gücü yüksek maliyetli bir politika eklenseydi ya da “LDAP Authentication” gibi dış bağlantı gerektiren ve araya bir de network latency ekleyen politika eklenseydi performans daha da hızlı bir şekilde düşecekti.

Politika Seçimi Best Practices

Politika Karmaşıklığı

Her bir politikanın ne kadar yük getireceğini bilmek ve tasarımı ona göre seçmek önemlidir.

Dış Bağlantılar

LDAP Authentication gibi dış bağlantı gerektiren politikalar network latency ekler ve performansı etkiler.

İşlem Gücü

Content filtering gibi işlem gücü yüksek maliyetli politikalar CPU kullanımını artırır.

Politika Sıralaması

Politikaların sıralaması ve koşullu çalıştırılması performansı etkiler.

Performans Metrikleri

Throughput (İşlem Hızı)

Throughput, saniyede işlenen istek sayısını gösterir. Durum D’de optimize edilmiş konfigürasyon ile:

GET İstekleri

15,000+ reqs/sec (2,000 thread)

POST 5KB İstekleri

13,000+ reqs/sec (2,000 thread)

POST 50KB İstekleri

2,700+ reqs/sec (2,000 thread)

Response Time (Yanıt Süresi)

Ortalama yanıt süreleri:

GET İstekleri

3-655 ms (thread sayısına göre)

POST 5KB İstekleri

3-701 ms

POST 50KB İstekleri

10-710 ms

Ölçeklenebilirlik

Dikey Ölçeklendirme

Tek node üzerinde 8,000 thread’e kadar test edilmiştir
2,000 thread’de optimal performans gözlemlenmiştir
Daha yüksek thread sayılarında throughput düşmeye başlar

Yatay Ölçeklendirme

Kubernetes altyapısı ile kolay ölçeklendirme
Load balancer ile çoklu gateway desteği
Otomatik pod scaling

Sonuçlar ve Öneriler

Ana Bulgular

Yüksek Performans

Optimize edilmiş konfigürasyon ile 15,000+ reqs/sec throughput elde edilmiştir.

Düşük Latency

GET istekleri için 3ms’den başlayan yanıt süreleri gözlemlenmiştir.

Bellek Verimliliği

Mesaj boyutu 10 kat artsa bile RAM kullanımında ciddi artış gözlenmemiştir.

Politika Etkisi

Basic Authentication gibi basit politikaların performans etkisi minimaldir.

Öneriler

Production Ortamı

Durum D konfigürasyonunu kullanın
Kubernetes ile yatay ölçeklendirme yapın
Monitoring ve alerting yapılandırın

Politika Yönetimi

Politikaların performans etkisini değerlendirin
Gereksiz politikaları kaldırın
Politika sıralamasını optimize edin

Kapasite Planlama

Beklenen yükü hesaplayın
Thread sayısını optimize edin
Yatay ölçeklendirme planı yapın

Sonraki Adımlar

Kapasite Planlama

Kapasite planlama rehberini inceleyin

Kapasite Planlama

Donanım gereksinimlerini öğrenin

Deployment Topolojileri

Deployment topolojilerini inceleyin

Performance Tuning

Performans optimizasyonu yapın

Başlangıç

Apinizer'ı Anlamak

​Özet

​Test Ortamı

​Yük Testi Topolojisi

Yük Test Sunucusu

Kubernetes Master & MongoDB

Elasticsearch

Kubernetes Worker

​Test Kurulumu

​1. Yük Test Sunucusu Kurulumu ve JMeter Yapılandırması

​2. NGINX Yapılandırması

NGINX Özellikleri

Yapılandırma

​3. Apinizer ve Log Server Kurulumu

​Yük Testinin Önemli Noktaları

Asenkron Loglama

Ağ Gecikmesi

Pod Yeniden Başlatma

JVM Monitoring

​Test Senaryoları

​Yük Testi Sonuçları

​GET İstekleri Sonuçları

​POST 5KB İstekleri Sonuçları

​POST 50KB İstekleri Sonuçları

​Sonuçların Yorumlanması

​Eş Zamanlı Kullanıcı ve İstek Sayısı

İstek

Session

​Ölçeklendirme

Dikey Ölçeklendirme

Yatay Ölçeklendirme

​Mesaj Boyutu Etkisi

​Bellek Kullanımı

​Politika Performans Etkisi

​Basic Authentication Politika Testi

​Politika Seçimi Best Practices

Politika Karmaşıklığı

Dış Bağlantılar

İşlem Gücü

Politika Sıralaması

​Performans Metrikleri

​Throughput (İşlem Hızı)

GET İstekleri

POST 5KB İstekleri

POST 50KB İstekleri

​Response Time (Yanıt Süresi)

GET İstekleri

POST 5KB İstekleri

POST 50KB İstekleri

​Ölçeklenebilirlik

​Sonuçlar ve Öneriler

​Ana Bulgular

Yüksek Performans

Düşük Latency

Bellek Verimliliği

Politika Etkisi

​Öneriler

​Sonraki Adımlar

Kapasite Planlama

Kapasite Planlama

Deployment Topolojileri

Performance Tuning

Özet

Test Ortamı

Yük Testi Topolojisi

Test Kurulumu

1. Yük Test Sunucusu Kurulumu ve JMeter Yapılandırması

2. NGINX Yapılandırması

3. Apinizer ve Log Server Kurulumu

Yük Testinin Önemli Noktaları

Test Senaryoları

Yük Testi Sonuçları

GET İstekleri Sonuçları

POST 5KB İstekleri Sonuçları

POST 50KB İstekleri Sonuçları

Sonuçların Yorumlanması

Eş Zamanlı Kullanıcı ve İstek Sayısı

Ölçeklendirme

Mesaj Boyutu Etkisi

Bellek Kullanımı

Politika Performans Etkisi

Basic Authentication Politika Testi

Politika Seçimi Best Practices

Performans Metrikleri

Throughput (İşlem Hızı)

Response Time (Yanıt Süresi)

Ölçeklenebilirlik

Sonuçlar ve Öneriler

Ana Bulgular

Öneriler

Sonraki Adımlar