bundle download should be faster.
zenworkswindowsservice.exe causing high cpu utilization at one cpu core when downloading a bundle.
looks like it is not multi-core capable.
by: Christian K. | over a year ago | Application Mgmt
Micro Focus Enhancement Requests Portal is moving. We are migrating the IDEAS from this site to the New Idea Exchange on May 6th. For more information on the new Idea Exchange please visit the Community FAQs.
Votes
27
speed up bundle download
by: Christian K. | over a year ago | Application Mgmt
Comments
I agree with that, but keep in mind the bundle status "downloading" means the bundle is downloaded and "decrypted" afterwards. - We have several examples where bundle download time is only 1,5 seconds in real time but bundle decryption takes a much longer time. So perhaps the status "downloading" should be splitted in two steps: "Downloading" and "Decrypting". That would deliver a much better user experience.
Thanks for that info!
How did you measure the times?
Is there an entry in the zmd-messages.logs showing downloading and decrypting?
I assume disabling encryption would help in case of large install bundles?!
Here is a copy of the message a novell technician send to me, after i criticized the long bundle download times:
"In the logs, it shows that the file took actuall 1.5 seconds, 1582 ms, see below to download from the zenworks server
[ZenworksWindowsService] [22] [] [ZenCache] [] [(Thread 22) PutFile returning C:\Program Files (x86)\Novell\ZENworks\cache\zmd\ZenCache\27bf486d-dd8a-47a5-be57-dbcab941a347 in 1582 ms]
The overhead is that the files have then to be decrypted, that is where the time is taken and this is the normal zenworks process.
[(Thread=22) The content package type is: Encrypted] as seen in the logs."
I agree that the time loss is caused by decrytion.
But why only decrypt with ONE core if there are 4 or 8...
This problem of single-threaded decryption is especially acute when utilizing an Install MSI action, as there is not a way to flag the content to not be compressed and encrypted, as one can do with an Install Directory action.
We install Adobe Creative Suite 5.5 through a bundle, and the main Install MSI action has to push down and then decrypt/decompress 3.77GB of installation files.
We use ENGL along with ZCM for deploying a very basic image and then installing software on top of that. The majority of the time involved in the build process is waiting for the single-threaded decryption/decompression of bundles.
That's the reason why we install large bundles like Adobe CS, Office Suite or Business Objects directly from a file share (OES) at the moment.
Update 3 - still no multicore support for decryption!
please vote...
Definitely needs to be addressed. I have a 400MB bundle and it's still "downloading" after 10 minutes. I didn't realize this until today regarding the decryption piece. That's good to know. I should have selected that during the bundle creation during upload.