We recently completed a CMOD upgrade to version 9.5. While the upgrade did bring us back under a supported version and offer better tools etc.; it also slowed down the loading of some of our PDF type reports.
While testing during the upgrade we found some of our larger reports were taking at least twice as long and even longer in most cases to index and load. According to the vendor who is doing our upgrade, IBM says the issue started with version 9 because Adobe changed their libraries around, which causes PDF loads to take longer to load. IBM says there is nothing they can do about it. Their only recommendation is to move our loading/indexing process to a Windows server (presently on AIX). Supposedly this process runs faster on a Windows server.
Wanted to see if anyone else has ran into this?
Thanks,
PDF indexing has always been problematic on non-Windows platforms, because a third party (not Adobe) writes the libraries that CMOD uses to do PDF Indexing. Because there isn't the same demand for PDF libraries on the other 'Multiplatform' OS's, (AIX, iSeries, z/OS, Linux, etc.) the libraries get less development, and less performance tweaks.
I'd still call this a 'performance regression', and ask IBM to have their vendor fix it -- but if the situation is causing trouble with delivery of data into your production systems, consider putting a Windows VM out on the network and doing your loading from there.
-JD.
Quote from: Justin Derrick on June 30, 2016, 12:19:54 PM
I'd still call this a 'performance regression', and ask IBM to have their vendor fix it -- but if the situation is causing trouble with delivery of data into your production systems, consider putting a Windows VM out on the network and doing your loading from there.
-JD.
Thanks JD...
Basically what IBM recommended...moving to windows. Something we did not want to do during the upgrade, but??????
For now we are considering just creating another ARSLOADER/ACIF? folder and let the big ones (actually, it is not the actual size of the PDF file itself, but seems to be the number of pages in the PDF) load separately. It seems that the loading is done "single threaded" so only one file loads at a time.(?) So, while the PDF file is loading other files sit there and wait.(?) Causing a back up.
Yeah, using multiple instances of arsload to get concurrent loads to Application Groups running is a great idea.
Even if you don't want one arsload thread for each Application Group, you can still run arsload with multiple -d parameters to 'group' different directories into queues.
Quote from: JBNC on June 30, 2016, 04:53:46 PM
Yeah, using multiple instances of arsload to get concurrent loads to Application Groups running is a great idea.
Even if you don't want one arsload thread for each Application Group, you can still run arsload with multiple -d parameters to 'group' different directories into queues.
I too have also seen this done extremely efficiently.
Quote from: JBNC on June 30, 2016, 04:53:46 PM
Yeah, using multiple instances of arsload to get concurrent loads to Application Groups running is a great idea.
Even if you don't want one arsload thread for each Application Group, you can still run arsload with multiple -d parameters to 'group' different directories into queues.
We basically do that now. We have 5 ARSLOADS running. We may have to setup another or new procedures to route the large files to one that is not used as often.
Thanks for the replies folks!