Empfohlene Systemumgebung

• Apache mit Reverse Proxy behandelt alle öffentlichen Anfragen 
• SSL Endpunkt wird auf dem Apache durchgeführt
• JBoss Application-Server wird nur über den Apache Reverse Proxy angesprochen

Apache Beispielkonfiguration (minimal)

<VirtualHost 192.168.101.38:80>

ServerName ica-pre.i-city.de

# recommend to minimize required bandwidth

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

# recommend to allow caching

ExpiresActive On
ExpiresByType text/javascript "access plus 4 hours "
ExpiresByType text/css "access plus 4 hours"
ExpiresByType image/png "access plus 4 hours"
ExpiresByType image/gif "access plus 4 hours"
ExpiresByType text/x-js "access plus 4 hours"

# required to avoid caching of dynamically created js files

ExpiresByType application/javascript "access plus 1 sec"

<Proxy / >
Order deny,allow
Allow from all
</Proxy>

ProxyPass /ica/ http://localhost:8080/ica/
ProxyPassReverse /ica/ http://localhost:8080/ica/

ProxyPreserveHost on

</VirtualHost>

Ab Version 1.5.x sind bei der Verwendung der API folgende Einstellungen hinzuzufügen

# API support ab Version 1.5.x

RewriteRule ^/ica/rest/api/([^/]+)/([^/]+)/service/(.*)/?(.*) /ica/rest/$3/$4 [PT,E=API_CALL:1,E=API_MIN:$1,E=API_MAJ:$2]

RequestHeader SET ICA_API_CALL_MIN "%{API_MIN}e"
RequestHeader SET ICA_API_CALL_MAJ "%{API_MAJ}e"

SSL-Unterstützung

Falls SSL-Unterstützung gewünscht ist (empfohlene Einstellung), dann muss der Anwendung noch das Request-Schema mitgeteilt werden. Dies erfolgt über eingeschleuste Header im Request. Damit kann die SSL-Terminierung von einer Firewall, einem Apache oder dem JBoss selbst transparent durchgeführt werden.

 

<VirtualHost *:443>

...

RequestHeader set ica_schema "https"
RequestHeader set ica_port "443"

...

</VirtualHost>

JBoss Konfiguration

In der standalone.conf müssen für die JVM folgende Parameter definiert werden:

Siehe auch Systemkonfiguration.

Host-Konfiguration (Netzwerk)

Die Mail-Versendung erfolgt über einen SMTP-Server. Der Server-Name des SMTP-Servers ist dabei fest (ica_smtp_host).

Dienst beispielsweise der "lokale Server" als SMTP-Server, so sollte folgender Eintrag in /etc/hosts vorgenommen werden:

127.0.0.1 ica_smtp_host

Wildfly-8.2.x

Logging Einstellungen

Datei: ./configuration/standalone.xml:

<use-deployment-logging-config value="false"/> under the <subsystem xmlns="urn:jboss:domain:logging:2.0"> 

Erlaubt der EAR-Anwendung eigene Logging Einstellungen zu haben. Die Einstellungen können dann über die Wildfly Console (core => logging) oder über das Command Line Interface angepasst werden.

Startup / Working Directory

Das Startup / Working directory muss für den User unter dem der Wildfly-Service läuft (Prüfung mit pwdx) schreibbar sein (Fehler in der Velocity-Lib), sonst können keine Velocity-Templates gerendert werden. 

Performance Issues

Logging-Directory, Database Directory

Das Logging Directory für den Applikation-Server (Wildfly) und das Verzeichnis für die Datenbank sollten möglichst performant sein. Für das Logging-Directory des Wildfly wird Writeback Einstellung und eine separate Partition empfohlen.

Datenbank Basics MySql oder MariaDB

Es wird generell empfohlen, die Datenbank NICHT auf dem gleichen Server zu betreiben, wie den Application Server (Best Practice). Die Einstellungen für die Datenbank sind immer abhängig von der Umgebung (verfügbares RAM, IO-Performance der Hardware, verfügbare Prozessoren, Systemnutzung). Hier werden lediglich auf einige wenige Basis-Einstellungen verwiesen. Für optimale Performance ist in jedem Fall eine Anpassung der Parameter an die Systemumgebung vorzunehmen. Weiter sollte die DB-Leistung regelmäßig überprüft und die Parameter ggf. angepasst werden.   

Grundlegende Einstellungen MySql / MariaDB

• Datenbank-Engine: InnoDB 
• Inno-DB Einstellungen
  • innodb_file_per_table = ON
  • open_files_limit = 12000
  • table_open_cache = 10000 
  • innodb_buffer_pool_size=(abhängig vom verfügbaren RAM)
    
  • innodb_log_file_size = Anpassen !
  • innodb_flush_method : Anpassung notwendig (hängt u.a. vom Unix und FS-Type ab)
• Sonstige 
  • tmp_table_size = (abhängig vom verfügbaren RAM)
    
  • key_buffer_size = (abhängig vom verfügbaren RAM)

Server / Service Konfiguration (Ubuntu 16.04):

• User Limit Files Limit erhöhen

  • /etc/security/system/mysql.service

    • mysql hard nofile 1024000 

    • mysql soft nofile 1024000
      

• Service Files LImit erhöhen
  • /lib/systemd/system/mysql.service
    
    • LimitNOFILE=infinity 
    • LimitMEMLOCK=infinit

Lastverteilung bei Einzelsystemen / Bottlenecks

Beim Betrieb der aller für die Ica-Anwendung benötigten Komponenten auf einem System sollte sich die Gesamtlast auf allen für die Erbringung benötigten Dienste verteilen.

Folgende Komponenten können als Bottleneck für Minderleistung verantwortlich sein:

• Web-Server
  • zu wenige Prozesse
  • zu wenige Netzwerkverbindungen
  • Hostname lookups langsam
  • keine Caching Einstellungen (Achtung: nicht alle JS-Dateien dürfen gecached werden!)
• Datenbank Server
  • zu wenig I/O Performance (daran zu Erkennen, dass die I/O Waits hoch sind)
  • zu wenig RAM
  • zu wenig Cache
  • zu wenig Threads
    
• Applikation Server
  • zu viel Logging
  • zu wenig Ram (JVM Einstellung)

Korrekte Lastverteilung (Beispiel für ein 4 CPU-System, Grenzlast):

• Application Server (50% Auslastung, bis zu einer Load < 2)
• DB-Server (25 % Auslastung, bis zu einer Load < 1)
• Web-Server (10 % Auslastung, bis zu einer Load < 0,25)

Die "korrekte" Lastverteilung bezieht sich auf die Systemleistung für interaktiven Betrieb, wenn keine langlaufenden Hintergrundprozesse aktive sind (Abrechnungen, System-Jobs). Falls im Hintergrund Jobs laufen, ist je Hintergrundjob eine CPU in jedem Fall voll ausgelastet (Abbildung von Tasks der JVM auf Systemprozesse).

Beseitigung von Bottlenecks

• Systemauslastung des Application Servers zu gering:
  • Prio 1: Reverse Proxy Einstellungen anpassen
    • siehe oben
  • Prio 2: JVM Parameter für Application Server anpassen
    • Prüfen Heap / Memory, Prozesse, physische CPUs
      
• DB-Sever hat keine Last
  • genug RAM
  • genug Threads
  • I/O Peformance
  • Caches / Buffers (insbesondere für die Transaktion Logs)
  • concurrent / max Connections
  • ggf. den Connection Pool im Applikation Server vergrößern
• Web-Server hat keine Last
  •  Netzwerk-Anbindung prüfen
  • Anzahl TCP Connections prüfen

Allgemeine System-Performance

Falls keine swap-Space eingerichtet wurde: Das ist ein NoGo!

• die Swap-Space sollte ca. 25-50% der Größe des RAM haben
• die Swap-Space sollte NIE genutzt sein (insbesondere nicht in virtualisierten Umgebungen)
• ggf. die swapiness des OS anpassen (Prüfen mit: sysctl -a| grep "swap" )
  

Die Swap-Space ist ausschliesslich ein Puffer für Hochlastsituationen und soll verhindern, dass das Gesamtsystem keine Fehlfunktionen aufgrund von fehlendem Speicher produziert. Die Benutzung der Swap space führt in jedem Fall zu einem signifikaten Einbruch der Systemleistung. Sollte die Swap-Space regelmäßig benutzt werden, fehlt Arbeitsspeicher!

In Test-Umgebungen ist die Verwendung der Swap-Space nicht ganz so kritisch. Sollte die Test-Umgebung jedoch in einer virtuellen Umgebung laufen, dann spiegelt die Verwendung der Swap-Space auch in einer Testinstallation der "best practice" für die Einstellung der virtuellen Maschinen im Host. Sprich: Der Systemadministrator hat die Kontrolle über das Gesamtsystem verloren und bekommt nicht mehr mit, wenn, bzw. wieweit eine virtuelle Maschine über die zugeteilten Grenzen hinaus Ressourcen beansprucht. Damit sinkt die Gesamtleistung der physischen Host-Maschine, was daran erkennbar wird, dass die I/O-Last unnötig ansteigt, was zu einer Erhöhung der CPU-Last auf anderen nicht ausgelasteten virtuellen Maschinen führt, obwohl diese überhaupt keine Last haben, was wiederum zu einer erhöhten Ram-Auslastung führt, die im Nachgang zu einem Swapping auf dem Host führt. 

Monitoring

Folgende Systemparameter sollte mittels Monitoring überwacht werden:

• Performance Überwachung
  • Load  / Load average (1, 5 and 15 Minutes)
  • Swap usage
• System Health
  • freie Plattenkapazität (total und inodes, ALLE Platten) 
  • Mindestanzahl Prozesse (mind. 1 Web-Server, 1 Db-Server, 1 Applikation-Server)
  • Maximalzahl Prozesse
• Sicherheit
  • Anzahl Prozesse (ggf. je User, insbesondere User des Applikation-Servers)
  • Anzahl User