Issue loading large files ( 25,000 pages +)

[bruce.mchendry]

Hi.
Firstly for reference our configuration is :
-> CMOD = 9.0.0.3
-> SQL2012  DB is remote
-> Viewing through Content Navigator v2.0.2 on AIX Websphere v8.0.0.5 in Internet Explorer 11 btw The AIX box has   a standard config of 4 GB of RAM and is an LPAR not physical dedicated server.

We recently have seen an issue where the clients are trying to open a 25k+ report in ICN and it's not loading. We do use load balancing for high availabilty but as a test I tried to different files one going through load balancing and the other bypassing it and going direct to the ICN server.
I then tried the same file and a couple similar in the thick desktop client and it opened in 2 minutes or less. Again for reference my office is the same location as the data center so the WAN is not an issue. Are there some configs or limits within CMOD that need looking at ? Has anyone else seen this ?

[jeffs42885]

What kind of file is it? Anything in the 88 message (If theres one being thrown)

[bruce.mchendry]

Hi,
It is actually a text file that gets FTP'd off our main frame. I checked and didn't see the 88 error in the client but I'll check the server logs too just to see.

[jeffs42885]

I've seen ulimits cause this issue before. Ours weren't high enough on an AIX system.

[Alessandro Perucchi]

Hello,

I have the impression that you two guys are speaking from 2 different things:

Bruce is speaking to display a document that is quite big with ICN and that doesn't work, and using the windows client it works, but takes nearly 2 minutes

jsamsung85 is speaking with archiving documents with arsload -> error 88 means cannot archive the document.

Am I right?

If I got it right, then I have no answer to Bruce... but at least I've solved the misunderstanding between you two!
The only answer I could provide is to active the trace in ICN (odwek trace for example) and check them in order to see what happens.
Maybe you'll find something interesting.
The other point that could be interesting would be to upgrade to ICN 2.0.3 if it is possible, or simple install a new ICN 2.0.3 on another server and connect to CMOD and try again. So you can have both ICN 2.0.2 and ICN 2.0.3 and test both of them...

If I got it wrong, I still don't know! :-) and let you two discuss :-)

-
Alessandro

[jeffs42885]

I've also seen a similar issue viewing large PDF files though I am not sure what the fix was. I believe it was outdated hardware.

[bruce.mchendry]

Hi,
Just back from a short vacation and getting caught up. We have engaged our IBM team and while I was off they've opened an internal PMR to find a fix. In fact we have a noon meeting today with IBM to get an update. Things on the table are the configs / settings of the AIX back end, Content Navigator and even SQL to ensure all are optimised. We'll see where all that goes. In the mean time thanks for the replies and information, everything helps ! I'll update when we figure this out as to what our solution ends up being.
Cheers

[Karole]

Yep, definitely check your ulimit -a output as the user running CMOD.   Data, stack, memory and nofiles should all be set to unlimited.   

[bruce.mchendry]

Thanks Karole I'll add it to the list.
Cheers

[Karole]

Thanks Karole I'll add it to the list.
Cheers

Any time!!

[jeffs42885]

Hey Bruce, Just curious what the fix was to this?

[bruce.mchendry]

Hi, been away a few days and just saw this. After much debate, and I'm still not entirely happy with it, the IBM guys decided to segment the reports into a series of smaller consecutive ones. It works so I don't have an issue from a technical perspective but it's not the most user friendly way to do it. Thankfully it's a fairly small group of reports in the big picture. Also almost disappointing to see how fast the complete report loads in the thick client direct to the server which of course is leaving ICN out of the solution. Sign offs in place on it so it's what we'll go ahead with.  Thanks for asking.
Cheers

[Justin Derrick]

Sorry I'm late to the game, but I've seen a similar issue when retrieving large documents.  The report was 80k pages (with large object support turned on), and an end user was retrieving the first chunk of the large object with the thick client, then issuing a find command.  The client was in a loop of retrieving 100 pages, then decompressing them, then searching them, then not finding the text, then fetching the next 100 pages, etc. etc.  The snag was that each round trip (including search time) was several seconds...  And if the search term didn't appear, then that was 800 round-trips.  It routinely took 20 to 30 minutes to get zero results.

We simply increased the large object size to 1000 pages, and performance increased dramatically.  Not only were there ten times fewer round trips to the server for large object 'chunks', the compression was more efficient, so each chunk size was reduced as well, meaning less data to send across the network, meaning quicker round-trips.

Consider trying it with larger object sizes?

-JD.

[bruce.mchendry]

Thanks Justin ! I have a daily meeting with the team and will bring that forward for discussion. Always appreciate the ideas and comments. And glad to have budget for a dev environment to try these things out too.    Cheers