NGINX-Server für lange Abfragen konfigurieren
Wenn Sie einen NGINX-Proxy-Server zur Verwaltung von Push-Benachrichtigungen für IBM Connections implementieren, können Sie ihn für einen Lastausgleich konfigurieren und so ein größeres Intervall für lange Abfragen bereitstellen.
Vorbereitende Schritte
Optional können Sie einen NGINX- oder einen NGINX Plus-Proxy-Server für die Verwaltung von Push-Benachrichtigungen implementieren, anstatt einen IBM® HTTP Server zu verwenden. Informationen zur Verwendung eines NGINX-Proxy-Servers für Push-Benachrichtigungen finden Sie im IBM developerWorks-Artikel NGINX and WebSphere Application Server.
Informationen zu diesem Vorgang
Wenn Sie einen NGINX-Proxy-Server implementieren, um Push-Benachrichtigungen an mobile Connections-Benutzer weiterzuleiten, und eine große Anzahl gleichzeitiger Clientverbindungen unterstützen möchten, sollten Sie möglicherweise einen Lastausgleich auf dem Server konfigurieren, um so ein größeres Intervall für lange Abfragen bereitzustellen. Durch Vergrößern des Intervalls für lange Abfragen können Clientverbindungen offen gehalten werden, bis der Server bereit ist, den Clients zu antworten, sodass die Antwortzeit verkürzt wird.
Die Einstellungen für den Lastausgleich sind optional; sie müssen nicht in einer bestimmten Datei hinzugefügt werden. Sie sollten jedoch innerhalb eines vorhandenen Bereichs (http, server, location usw.) verschachtelt sein.
Im folgenden Beispiel sind die Einstellungen im Hauptbereich von "location" in der Konfigurationsdatei nginx.conf verschachtelt.
........
http{
server{
.............
location / {
location /push/ {
proxy_pass https://pns_ssl;
proxy_ssl_name $host;
proxy_ssl_server_name on;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Upgrade $http_upgrade;
proxy_buffering off;
keepalive_timeout 160s;
keepalive_requests 100000;
proxy_read_timeout 900s;
proxy_connect_timeout 75;
proxy_send_timeout 600;
send_timeout 600;
proxy_ignore_client_abort on;
}
proxy_pass https://backend_secure;
........
}
}
upstream pns_ssl {
.......
least conn;
server server1:9447 max_fails=0 fail_timeout=60s;
server server2:9447 max_fails=0 fail_timeout=60s;
keepalive 512;
sticky cookie srv_id expires=2h domain=.domain.com path=/;
}
upstream backend_secure {
.......
server webserver:443 max_fails=0 fail_timeout=90s;
}
}