wir Lizmap-Anwender haben nach dem Upgrade vom QGIS-Server 3.34.15 auf 3.40.x massive Geschwindigkeitsprobleme, insbesondere beim ersten Laden der Projekte.
Wurde so etwas auch in Verbindung mit dem QWC2 beobachtet?
Habt Ihr grundsätzliche Erfahrungen mit der Option des parallelen Renderns mit mehreren Threads?
Einstellungen am Beispiel von Apache:
– FcgidInitialEnv QGIS_SERVER_PARALLEL_RENDERING 1
– FcgidInitialEnv QGIS_SERVER_MAX_THREADS 8
Funktioniert das, bzw. gibt es dadurch mehrere aktive “qgis_mapserv.fc”-Prozesse?
Über eine Rückmeldung würde ich mich freuen.
Viele Grüße
Günter
Probleme mit der Geschwindigkeit, die auf ein Update zu QGIS Server 3.40.x zurückzuführen sind, kann ich leider (oder glücklicherweise) nicht bestätigen.
Ich habe unsere QGIS Server auf 3.40.3 umgestellt (3.40.4 LTS ist für den QWC-Stack noch nicht verfügbar) und kann wie gehabt im normaler Geschwindigkeit initial die Projekte laden.
Wie sieht es bei anderen damit aus?
Bezüglich des parallelen Renderns kann ich jedoch einen Hinweis geben, dass war bei uns gerade frisch letzte Woche erst relevant:
Dass durch das Setzen von QGIS_SERVER_PARALLEL_RENDERING mehrere Prozesse parallel bearbeitet werden, stimmt so nicht! Hatte ich bisher aber auch so interpretiert. Was hier passiert, ist das dennoch immer nur ein Prozess nach dem anderen bearbeitet wird, der QGIS Server für diese Bearbeitung jedoch mehrere Threads verwendet.
vielen Dank für die schnelle Rückmeldung.
Hatte ich mir beinahe schon gedacht. Die Geschwindigkeitsprobleme liegen wohl an der speziellen Darstellung der Legendenbilder der Layer in Lizmap. Ist dann wohl doch eher ein Lizmap-Problem, auch wenn sich hier beim QGIS-Server ab 3.40. was geändert hat.
Und das mit den parallelen Rendern habe ich auch so befürchtet/beobachtet.
Danke für den Hinweis. Werde ich /wir testen.
Die lange Projektladezeiten sind nach unserer Beobachtungen schon immer ein Problem gewesen, es kann sein dass abhängig von Projektinhalt zwischen Versionen dann auch spührbaren Unterschiede gibt (grundsätzlich dauert das Parsen des XMLs der QGS Datei lange, und desto mehr XML geparsed werden muss, desto länger dauert es).
QGIS_SERVER_MAX_THREADS konfiguriert nur die anzahl parallelen rendering Threads innerhalb eines requests. Unserer Erfahrung nach bringt es selten eine spührbare Beschleunigung (der Overhead der Multithread-Verteiliung kann gut den dadurch erreichten Performancegewinn annullieren). Kommt aber auch hier auf die Daten an.
Mehrere FCGI instanzen müssen auf FCGI Ebene konfiguriert werden (etwa FcgidMinProcessesPerClass / FcgidMaxProcessesPerClass in Apache mod_fcgid).
Grundsätzlich gilt aber auch hier: Jedesmal wenn eine neue Instanz gestartet wird, hat die Instanz ein Projekt noch nie gelesen, dann kann es länger dauern. Danach bleibt das Projekt für die Lebenszeit der Instanz gecached und die Antworten sind entsprechend schnell.
Danke für Deine Rückmeldung und Einschätzung.
Ich befürchte auch, dass die Änderung dieser Variablen nichts oder nur wenig bewirkt. Zumal ja fcgidminprocessesperclass standardmäßig auf 3 und fcgidmaxprocessesperclass standardmäßig auf 100 steht, wenn ich es richtig verstehe.
Meine Beobachtung ist auch, dass “schlanke” QGIS-Projekte" auf jeden Fall sinnvoll sind. Auch durch das Aufteilen der Projekte und die Bereitstellung eigener WMS-Dienste (die dann parallel abgearbeitet werden) habe ich gute Erfahrungen gemacht.
Allerdings finde ich es auch sehr schade, dass der QGIS-Server die Recourcen der modernen Server (viele Prozessorkerne, viel RAM-Speicher) nicht besser nutzen kann.
Vielleicht gibt es hier Optimierungsmöglichkeiten, die wir als Client-Anwender vom QGIS-Server evtl. sogar mal gemeinsam angehen können.