slow publishing of qvw files

[markusjahr]

Hello,

the distribution and publishung of qvw files is very slow.

We have 2 servers, a reload server and a server working as accesspoint. 

The storage where the files are copied are nfs (SSD).

Publishing qvw files direct to the publisher to local disc is also slow (SSD).

Publishing to a normal folder is fast.

CPU and RAM are not the problems, there are always enough free ressources.

in the Task logs we found this:

(28.11.2023 17:50:01) Information: <Global method="FileWrite"><h>0</h><Pos>83886080</Pos><Buffer /></Global>

(28.11.2023 17:50:01) Information: ExecuteWithAttachments returned no data in buffer.

(28.11.2023 17:50:01) Information: <Global></Global>

The support already checked all logfiles of the operating system and the qlikview server but there were no irregular and suspicious entries.

the following tips of the support are not working or brought no improvement:

https://community.qlik.com/t5/Official-Support-Articles/Scaling-the-QlikView-Publisher/ta-p/1717686

https://community.qlik.com/t5/Official-Support-Articles/QlikView-and-its-backend-File-Share-System/t...

https://community.qlik.com/t5/Official-Support-Articles/QlikView-Tasks-and-reloads-do-not-trigger-ar...

We use the publisher in Version12.80.20000.0 on the reload server.

What could be the reason for slow distribution and are there some hints to solve this problem?

Thank you.

[marcus_sommer]

Are it a new distribution-jobs or existing ones and the issues are occurring after the upgrade to 12.8? By an upgrade what was further changed on Qlik settings and/or the OS and/or the environment? Further are all Qlik services running on the same release?

Beside this if you could exclude any relation to the CPU/RAM consumption and like it sounds also a significantly impact from the general network/storage performance - the issue hints for any waiting respectively timing causes. This means a distribution-task isn't directly executed else between the authentication + authorization (querying the active directory, certificates, ...) happens some back and forth - this includes also any proxy & load-balancers in the chain - and/or they are intentionally delayed (in regard to avoid any overload or any misusage).

If there is anything in this way there should be also hints within the various log-files. Also using the process-monitor and/or tools like Wireshark should be helpful to detect the causes behind the issue.

[markusjahr]

Hallo,

es ist eine bestehende Distribution erst nach dem Update auf 12.8 war mir aufgefallen das in den Tasklogs die :eilen:

(28.11.2023 17:50:01) Informationen: <Global method="FileWrite"><h>0</h><Pos>83886080</Pos><Buffer /></Global>

(28.11.2023 17:50:01) Information: ExecuteWithAttachments hat keine Daten im Puffer zurückgegeben.

(28.11.2023 17:50:01) Informationen: <Global></Global>

unzählige Male aufgeführt werden. Dazwischen stehen ab und zu die % der bereits kopierten Datenmenge.

Aber eine Verschlechterung haben wir seit dem Update nicht bemerkt auch vorher war es schon so langsam.

Vielleicht noch ein Beispiel dazu wenn man eine 13GB Manuell zwischen den Servern hin und her kopiert dauert der Vorgang nur wenige Sekunden über den Qlikview Distribution Service dauert dies weit über 15 Minuten.  

Weiterhin ist mir aufgefallen das die Übertragungsgeschwindigkeit über den Distribution Service max. 27 MBit/s beträgt (Auch wenn die Datei auf dem Reloadserver selbst veröffentlicht wird). Schon der Upload vom Reloadserver ist so gering.

Vielleicht ist auch ein Indiz das ein Userabruf in der QMC sehr lange benötigt (2 MInuten) 

[marcus_sommer]

Ich könnte mir vorstellen, dass hier nicht direkt auf die Storages zugegriffen wird, sondern hier irgendeine Umleitung, wie über einen Proxy und/oder re-directs (vielleicht für HTTP/HTTPS + Zertifikate o.ä.) drin ist, was dann limitiert.

Als Ausgangspunkt schaue mal, ob es bei Euch alte Tickets hinsichtlich der QlikView Services Kommunikation Untereinander und auch innerhalb des Unternehmensnetzwerk gibt, denn hier musste ganz bestimmt was konfiguriert werden.

[markusjahr]

Das Geschwindigkeitsproblem besteht ja auch wenn auf die lokale Festplatte (C:\) wird.  Da dürfte das Netzwerk ja eigentlich gar nicht angefasst werden. 

Ich hatte die Qlikview Infrastruktur in der Vergangenheit aufgebaut.

Wir haben in den vergangenen Wochen die beiden Server von HDD auf SSD umziehen lassen weil wir annahmen das es daran läge, aber geändert hat sich leider nichts.

[marcus_sommer]

Wie genau der Storage-Zugriff am Ende erfolgt (SMB ?), kann ich nicht sagen, aber mitten drin ist auf jeden Fall jede Menge Internet-Kommunikation, denn die Services kommunizieren untereinander per HTTP/HTTPS.

Ist die Transfer-Geschwindigkeit direkt gemessen/beobachtet worden oder schlicht abgeleitet aus der Filegröße und der benötigten Zeit? Hintergrund der Frage ist es, die Ursachen dahingehend einzugrenzen, ob irgendwo Wartezeiten/Timeouts für was auch immer drin sind und der Traffic danach hoch ist oder ob der Traffic selbst langsam und (relativ) kontinuierlich ist?

[marcus_sommer]

Noch was, falls irgendwelche Security Tools laufen, deaktiviert die mal. Ähnlich auch mit Backup/Index Services/Tools oder ähnlichem, die parallel mitlaufen.

[markusjahr]

Wie genau der Storagezugriff abläuft werde ich in Erfahrung bringen.

die Transfergeschwindigkeit wurde auf dem Reloadserver als auch an dem Accesspoint Server im Ressourcenmonitor gemessen/abgelesen.

Securitytools etc sind nicht aktiv

[marcus_sommer]

Timing/Timeouts scheinen somit als Ursache eher unwahrscheinlich, denn hierbei müssten sich längere Pausen mit kürzeren und vergleichsweise höheren Transfergeschwindigkeiten abwechseln. Wenn es vergleichsweise konstant und langsam dahin tröpfelt, deutet es mehr auf irgendeinen Bypass.

[marcus_sommer]

In der Antwort zu einem ähnlichen Fall: Re: Application failed with Errors in QMC - Qlik Community - 1635366 gibt es den Hinweis, mal nach der Granularität der Log-Files zu schauen und diese auf High zu setzen. Möglicherweise gibt es hierbei dann doch Hinweise.

Ebenso, habt ihr mal in die OS log-files geschaut?