Q:
Topic thread:
Printer Systems (PRINT)
PSF/AIX
PRINT XPSF6000
Customer is complaining about AFPSPLIT performance :
- It takes him less than 10 minutes to compose 20 Kpages with ACIF
- It takes him 50 minutes to extract 20 Kpages from this file with
afpsplit.
Questions :
1) What do you think about these figures ?
2) Can he use something else to extract pages ?
3) Can he expect any improvement of this function, even with
InfoPrint Manager ?
4) Can he open a PMR ?
A:
What model RS/6000 is the customer using and are they perhaps hitting
CPU or I/O bottlenecks? Also, what is the size of the input file to
ACIF, and what is the size of the output file from ACIF? The original
question just mentioned 20K pages. For your specific questions:
R1) That is a hard question to answer ... I can say that no one has ever
looked at afpsplit performance because it was originally put
together to solve a particular problem (extracting a range of pages
out of a file) on an occasional and interim basis; the problem
it was meant to address was the lack of forwardspace capability
which is now available in InfoPrint Manager. To my knowledge, we've
not received any other complaints about its performance so I don't
know whether other customers aren't using it on files the size that
your customer is, or if there's something else going on on your
system that might be causing the performance problems (like disk
contention or cpu utilization), or if there's a performance
issue.
R2) We know of no other tools existing on AIX that extract AFP pages
from a document.
R3) afpsplit was not modified for InfoPrint Manager, so its performance
characteristics would be the same.
R4) A performance concern is not really a defect, so I don't believe
that Level 2 would accept this as a PMR though you could try.
And since PSF/AIX is functionally stabilized, there's no priority
or funding provided for enhancements to it. You may wish to take
this up with the brand manager, Randy Larsen.
I've spoken with the developer of afpsplit, and he believes that
afpsplit is coded about as efficiently as possible and doesn't know of
any ways that he could speed up the processing. The code includes
use of buffering to improve efficiency, and it only processes an AFPDS
file up to the last page requested on the afpsplit command then ends,
so it doesn't unnecessarily process pages.
For example, afpsplit will first extract any resource group that might
exist (inline resources) from the front of the file; if there are lots
of inline resources, that may take some time. Then afpsplit reads
every structured field looking for BPG and EPG records to count the
pages and match them against the value specified on the -f flag to
know where to start the extraction. Then it will continue searching
each structured field for the BPG/EPG and match the number of pages
processed against the -p flag to extract and write those specified
pages. When it finishes processing the last page you're requested, it
stops; it does not process any additional structured fields.
For example:
1) The best case is if you need to extract the first page of a file.
It will extract any inline resources, then find and output that first
page, and end.
2) The worst case is if you need to extract the last page of a long
file. It will extract any inline resources, then read the entire file
until it finds that one page at the end of the document; it will write
that page and end.
If you have lots of pages, you'll have quite a bit of I/O as afpsplit
reads the file. And if the pages in the job are quite complex, then
there could be many structured fields through which it must traverse.
So I think the performance you're seeing, unless constrained by some
customer-specific factor that you could address, is as good as can be
expected. There are no obvious areas in afpsplit that the developer
knows of to change to improve performance.
Thanks for using WWQ&A.
Q:
I transmitted your answer to customer. He explained me how he built
his datastream, and his answer explained many things.
His PAGEDEF/FORMDEF are very complex: they call 70 different overlays
using conditional processing. I told him that he could use instead
relative printline to simplify his composition. He will rewrite his
application, and I think we will not hear anymore about AFPSPLIT
performance ...
I'm closing this item.
A:
Thank you very much for the update. Closing.
S e a r c h - k e y w o r d s:
psf/6000 psf/aix psf aix infoprint manager ipmgr pod afpsplit acif
performance
WWQA: ITEM: RTA000149931 ITEM: RTA000149931
Dated: 03/1999 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:38
Comments or suggestions?
Contact us