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

  1. G1GC Tuning: JVM-Flags optimiert (Xms8G, Xmx16G, MaxGCPauseMillis=200) → GC Pause 320ms → 90ms
  2. Kubernetes HPA: 2-8 Pods, Auto-Scaling bei 70% CPU → 99.9% Uptime, kein Monatsende-Bottleneck mehr
  3. Database Indizes: 15 Indizes auf häufig abgefragte Tabellen → Query Time 150ms → 55ms
  4. Redis Session-Cache: Redis Cloud (100MB RAM, 30€/Monat) → Session Lookup 150ms → 2ms
  5. 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.

Jetzt kostenlosen Audit sichern →

🔒 Unverbindlich | ✓ Keine Zahlungsdaten erforderlich | 📧 Antwort in 24h

Weitere Artikel zur IX25-Migration