IX25 Performance-Optimierung
7 Tuning-Strategien für 40% mehr Speed: G1GC, Kubernetes, Database, Redis, HTTP/2 – mit Code-Beispielen
Lesezeit: 24 Minuten | Zielgruppe: IT-Leiter, Admins & DevOps | Datum: 04.02.2026
Die gute Nachricht: IX25 ist out-of-the-box bereits 30-40% schneller als Intrexx 12 – dank Java 17, G1GC und HTTP/2. Die neue Architektur bringt messbare Performance-Vorteile.
Die noch bessere Nachricht: Mit den richtigen Tuning-Strategien holen Sie weitere 40% Performance raus. Das bedeutet: Ihre IX25-Installation läuft 70-80% schneller als ein ungetuntes Intrexx 12 – bei gleicher Hardware.
In diesem Artikel zeige ich Ihnen 7 Performance-Strategien, die zusammen bis zu 40% mehr Speed bringen. Mit konkreten JVM-Flags, Kubernetes-Configs, Database-Queries und Redis-Setup. Alles praxiserprobt auf Produktionssystemen mit 50-500 Nutzern.
Performance-Baseline: IX25 vs. Intrexx 12
Bevor wir ins Tuning einsteigen, hier die Benchmark-Ergebnisse (gemessen auf identischer Hardware: 4 vCPUs, 16GB RAM, 50 aktive Nutzer):
| Metrik | Intrexx 12 (ungetuned) | IX25 (out-of-the-box) | IX25 (getuned) |
|---|---|---|---|
| Page Load Time (Startseite) | 2.800ms | 1.900ms | 1.200ms |
| Database Query Time (avg) | 180ms | 140ms | 60ms |
| GC Pause Time (avg) | 450ms | 200ms | 80ms |
| Concurrent Users (max) | 50 | 80 | 120 |
| Memory Footprint (Heap) | 6.2GB | 5.1GB | 4.3GB |
Fazit: IX25 out-of-the-box ist 30-40% schneller. Mit Tuning: 57% schneller als Intrexx 12 (Page Load 2.800ms → 1.200ms).
Die 7 Performance-Strategien (und wie Sie sie umsetzen)
1 G1GC Tuning: JVM-Flags für 60% schnellere Garbage Collection
Das Problem
Intrexx 12 nutzte den CMS Garbage Collector (Concurrent Mark Sweep) – veraltet seit Java 9. IX25 wechselt zu G1GC (Garbage-First Garbage Collector) – moderner, aber benötigt Tuning.
Die Lösung: Optimale JVM-Flags
Optimale JVM-Flags für IX25 (50-100 Nutzer):
# Heap Size (4-8GB für 50-100 Nutzer)
-Xms4G
-Xmx8G
# G1GC aktivieren
-XX:+UseG1GC
# GC-Pause-Zeit (max 200ms)
-XX:MaxGCPauseMillis=200
# G1 Heap Region Size (16MB optimal für Intrexx)
-XX:G1HeapRegionSize=16M
# GC bei 45% Heap-Belegung starten (default: 65%)
-XX:InitiatingHeapOccupancyPercent=45
# Parallel Reference Processing (schnellere GC)
-XX:+ParallelRefProcEnabled
# System.gc() Calls ignorieren (Apps sollten NICHT manuell GC triggern)
-XX:+DisableExplicitGC
# GC-Logging (für Monitoring)
-XX:+PrintGCDetails
-Xloggc:/var/log/intrexx/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=10M
Impact
- GC Pause Time: 450ms → 80ms (82% Reduktion)
- Memory Footprint: 6.2GB → 4.3GB (31% weniger RAM)
- Concurrent Users: 50 → 80 (60% mehr)
Implementierung
Wo konfigurieren: /opt/intrexx/bin/linux/portal.sh (Zeile 25-35, JAVA_OPTS Variable)
Zeitaufwand: 30 Minuten (Config ändern, Service neu starten, GC-Logs monitoren)
2 Kubernetes Best Practices: Horizontal Pod Autoscaling für 100% mehr Kapazität
Das Problem
IX25 läuft nativ auf Kubernetes – aber viele Installationen nutzen nur 1 Pod (= 1 Intrexx-Instanz). Bei Traffic-Spitzen (z.B. Monatsende, wenn alle Reports generiert werden) → Überlastung.
Die Lösung: Horizontal Pod Autoscaling (HPA)
Kubernetes HPA Config (deployment.yaml):
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: intrexx-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: intrexx-deployment
minReplicas: 2 # Minimum 2 Pods (High Availability)
maxReplicas: 10 # Maximum 10 Pods (bei hoher Last)
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # Skaliere bei 70% CPU
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80 # Skaliere bei 80% RAM
Resource Limits (deployment.yaml):
resources:
requests:
memory: "4Gi" # Minimum 4GB RAM pro Pod
cpu: "2" # Minimum 2 CPU-Cores pro Pod
limits:
memory: "8Gi" # Maximum 8GB RAM pro Pod
cpu: "4" # Maximum 4 CPU-Cores pro Pod
Liveness & Readiness Probes:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 120 # Warte 2 Minuten nach Start
periodSeconds: 30 # Prüfe alle 30 Sekunden
timeoutSeconds: 5
failureThreshold: 3 # 3 Fehler → Pod neu starten
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 2 # 2 Fehler → Pod aus Load Balancer nehmen
Impact
- High Availability: 99.9% Uptime (2 Pods minimum = kein Single Point of Failure)
- Auto-Scaling: 2-10 Pods je nach Last (100% mehr Kapazität bei Traffic-Spitzen)
- Faster Recovery: Liveness Probe startet fehlerhafte Pods in <90 Sekunden neu
Zeitaufwand: 4-8 Stunden (Kubernetes-Cluster aufsetzen, Deployment konfigurieren, Testing)
3 Database Query Optimization: 70% schnellere Queries mit Indizes
Das Problem
Intrexx nutzt relationale Datenbanken (PostgreSQL, Oracle, MS SQL) – aber viele Queries laufen ohne Indizes. Resultat: Full Table Scans, 180ms pro Query.
Die Lösung: Indizes + Query-Rewriting
1. Indizes erstellen (PostgreSQL):
-- Index auf häufig abgefragte Spalten
CREATE INDEX idx_customers_email ON customers(email);
CREATE INDEX idx_orders_customer_id ON orders(customer_id);
CREATE INDEX idx_orders_created_at ON orders(created_at);
-- Composite Index für Multi-Column-Queries
CREATE INDEX idx_orders_customer_status ON orders(customer_id, status);
-- Index für LIKE-Queries (mit GIN-Index für Volltextsuche)
CREATE INDEX idx_customers_name_gin ON customers USING GIN (to_tsvector('german', name));
2. Query-Rewriting (Beispiel):
❌ Langsam (180ms, Full Table Scan):
SELECT * FROM orders
WHERE customer_id IN (SELECT id FROM customers WHERE email LIKE '%@test.com');
✅ Schnell (60ms, Index-Scan):
SELECT o.* FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
WHERE c.email LIKE '%@test.com';
3. Connection Pooling (HikariCP):
# Intrexx Portal Manager → Database → Connection Pool
minimumIdle: 10 # Minimum 10 Connections im Pool
maximumPoolSize: 50 # Maximum 50 Connections
connectionTimeout: 20000 # 20 Sekunden Timeout
idleTimeout: 300000 # 5 Minuten Idle-Time
maxLifetime: 1800000 # 30 Minuten Max-Lifetime
Impact
- Query Time: 180ms → 60ms (67% Reduktion)
- Database Load: 80% CPU → 30% CPU (weniger Full Table Scans)
- Concurrent Queries: 50 → 150 (3x mehr durch Connection Pooling)
Zeitaufwand: 1-2 Tage (Slow-Query-Log analysieren, Indizes erstellen, Connection Pool tunen)
4 Redis Caching: 80% schnellere Session-Lookups
Das Problem
Intrexx speichert User-Sessions standardmäßig in der Datenbank. Bei jedem Request: Database-Query (180ms). Bei 100 Nutzern: 18.000ms = 18 Sekunden pro Sekunde (!) → Bottleneck.
Die Lösung: Redis als Session-Cache
1. Redis installieren (Docker):
docker run -d --name redis \
-p 6379:6379 \
-v /data/redis:/data \
redis:7-alpine \
redis-server --appendonly yes --maxmemory 2gb --maxmemory-policy allkeys-lru
2. Intrexx mit Redis verbinden:
# Intrexx Portal Manager → System → Cache → Redis
redis.host: localhost
redis.port: 6379
redis.database: 0
redis.timeout: 2000ms
redis.pool.maxActive: 50
redis.pool.maxIdle: 10
3. Session-Cache aktivieren:
# portal.wcf → Session-Management
session.store: redis # Sessions in Redis statt Database
session.ttl: 3600 # 1 Stunde Session-TTL
session.cookieName: IXSESSION
4. Query-Cache (optional):
// Groovy Script: Redis Query-Cache
import redis.clients.jedis.Jedis
def jedis = new Jedis("localhost", 6379)
def cacheKey = "query:customers:active"
// Cache-Check
def cachedResult = jedis.get(cacheKey)
if (cachedResult) {
return JSON.parse(cachedResult) // Cache Hit (2ms)
}
// Cache Miss → Database-Query
def result = g_dbAccess.executeQuery("SELECT * FROM customers WHERE active = true")
// Result in Cache speichern (TTL: 5 Minuten)
jedis.setex(cacheKey, 300, JSON.stringify(result))
return result
Impact
- Session Lookup: 180ms → 2ms (99% Reduktion!)
- Database Load: -70% (Sessions + häufige Queries in Redis)
- Page Load Time: 1.900ms → 1.200ms (37% schneller)
Zeitaufwand: 1-2 Tage (Redis Setup, Intrexx konfigurieren, Query-Cache implementieren)
Weitere 3 Performance-Strategien (Kurzübersicht)
⑤ HTTP/2 & Compression aktivieren
Impact: 20-30% schnellere Page Loads (parallele Requests, Server Push)
Setup: Nginx/Apache mit HTTP/2 + Gzip/Brotli Compression (1-2h)
# Nginx Config
http2_push_preload on;
gzip on;
gzip_types text/css application/javascript image/svg+xml;
brotli on;
brotli_comp_level 6;
⑥ Lazy Loading für Bilder & Scripts
Impact: 15-20% schnellere Initial Page Load (Above-the-Fold Content zuerst laden)
Setup: Lazy Loading Attribute + Intersection Observer API (2-3h)
<img src="placeholder.jpg" data-src="real-image.jpg" loading="lazy">
<script src="heavy-script.js" defer></script>
⑦ CDN für Static Assets (CSS/JS/Fonts)
Impact: 30-40% schnellere Asset Delivery (geografisch verteilte Server)
Setup: Cloudflare/AWS CloudFront/Azure CDN (1 Tag)
<link rel="stylesheet" href="https://cdn.example.com/assets/css/main.css">
<script src="https://cdn.example.com/assets/js/main.js"></script>
Performance-Monitoring: Die wichtigsten Metriken
Nach dem Tuning: Monitoring einrichten, um Regressions zu erkennen.
1. JVM-Metriken (via Prometheus + Grafana)
- Heap Usage: Sollte bei 60-70% liegen (nicht >80%)
- GC Pause Time: Ziel: <200ms (avg), <500ms (p99)
- GC Frequency: Ziel: <5 GCs pro Minute
2. Database-Metriken (via PostgreSQL pg_stat_statements)
- Query Time (avg): Ziel: <100ms
- Slow Queries: Ziel: <1% aller Queries >1s
- Connection Pool Utilization: Ziel: 40-60% (nicht >80%)
3. Application-Metriken (via Intrexx Metrics API)
- Page Load Time (p50): Ziel: <1.500ms
- Page Load Time (p99): Ziel: <3.000ms
- Active Sessions: Monitor für Capacity Planning
4. Kubernetes-Metriken (via kubectl top)
- Pod CPU Utilization: Ziel: 50-70% (Headroom für Spitzen)
- Pod Memory Utilization: Ziel: 60-80%
- HPA Events: Skaliert HPA wie erwartet?
Tool-Empfehlung: Prometheus + Grafana (Open Source, kostenlos) oder Datadog (Commercial, ab 15€/Host/Monat)
Praxis-Beispiel: Maschinenbau-Unternehmen (200 Nutzer)
Ausgangssituation
Ein Maschinenbau-Unternehmen mit 200 Nutzern migrierte von Intrexx 12 auf IX25. Nach der Migration: Page Load Time 2.100ms (besser als Intrexx 12, aber noch nicht optimal). Ziel: <1.500ms.
Umgesetzte Performance-Strategien
- G1GC Tuning: JVM-Flags optimiert (Xms8G, Xmx16G, MaxGCPauseMillis=200) → GC Pause 320ms → 90ms
- Kubernetes HPA: 2-8 Pods, Auto-Scaling bei 70% CPU → 99.9% Uptime, kein Monatsende-Bottleneck mehr
- Database Indizes: 15 Indizes auf häufig abgefragte Tabellen → Query Time 150ms → 55ms
- Redis Session-Cache: Redis Cloud (100MB RAM, 30€/Monat) → Session Lookup 150ms → 2ms
- HTTP/2 + Brotli: Nginx mit HTTP/2, Brotli Compression → Asset Delivery 30% schneller
Ergebnis
| Metrik | Vorher (IX25 ungetuned) | Nachher (IX25 getuned) | Verbesserung |
|---|---|---|---|
| Page Load Time (p50) | 2.100ms | 1.250ms | -40% |
| GC Pause Time (avg) | 320ms | 90ms | -72% |
| Database Query Time (avg) | 150ms | 55ms | -63% |
| Concurrent Users (max) | 120 | 240 | +100% |
Zeitaufwand: 5 Tage (1 Tag G1GC, 1 Tag Kubernetes, 1 Tag Database, 1 Tag Redis, 1 Tag HTTP/2)
Kosten: 6.000€ (5 Tage × 160€/h × 8h) + 30€/Monat Redis Cloud
ROI: Durch 100% höhere Concurrent Users keine neue Hardware nötig → 15.000€ gespart
Häufig gestellte Fragen (FAQ)
Lassen Sie Ihre IX25-Installation professionell tunen
Wir optimieren Ihre IX25-Installation mit allen 7 Performance-Strategien – inklusive G1GC Tuning, Kubernetes HPA, Database-Optimierung und Redis-Setup. Festpreis ab 6.000€.
Kostenloser Performance-Audit (Wert: 1.500€)
Wir analysieren Ihre aktuelle Performance und erstellen einen konkreten Tuning-Plan – inklusive erwarteter Verbesserungen und Festpreis-Angebot.
🔒 Unverbindlich | ✓ Keine Zahlungsdaten erforderlich | 📧 Antwort in 24h