Spool: bad performance with Access Type G

[former_member59207]

Hi there,

we are having a Problem when using frontend printing via Access type G. The Performance in printing to a PDFcreator is extremely slow (about 1 page per second).

Formerly we used Access type F with saplpd. The printout of lets say 500 pages then took about 10 seconds until the pdfcreator came up. But now with Access type G it takes about 10 minutes. One thing to notice ist that when observing the printing in the Windows Printer, the first ca. 25 Pages are finished very fast (about 1-2 Seconds). After that the slowdown sets in (1 sec per page).

Does anyone have an idea why the performance went down so badly?

We are using sapgui 740 patch 4.

sap_basis 740 sp12, Kernel 742

Greetings

SL

[former_member59207]

two Videos:

Develop System System (slow):

https://www.youtube.com/watch?v=_YYrLjjaPAE&feature=youtu.be

Legacy System (fast)

https://www.youtube.com/watch?v=OigDIwYyE8M&feature=youtu.be

[michael_szardenings]

Hi Sven,

you should open a problem report on BC-CCM-PRN.

However you could check where the time is consumed. Create a log file according to KBA

http://service.sap.com/sap/support/notes/1780896

Do a test print on you G printer to the PDF Creator. Choose a medium size spool request. After the print get the sapwin_xxx.log file according to the KBA.

Search for the line

Enter Open_DC.

Then go to the end of the log file. There should be the entry

Leave PrintSAPWINFile with return code 0.

The time difference between the first and the last line is the processing time in the printer driver. If this is the large block of time compared to the rest (which I assume) there is nothing you can do than looking for another PDF tool. However from my experience most of them are not very quickly, at least not on current Windows.

The internal processing of SAPLPD and access method G is quite the same. So theoretically on the same machine with the same printer driver the same spool request should approximately have the same processing time with either SAPLPD or a G printer.

Make sure to switch the Level of log information to Default and switch off the Keep log file flag in productive environment. This makes a large difference. To get only the processing time set the Level of log information to Default, switch on the Keep log files and Log time consumption flags.

Kind regards

Michael

[former_member59207]

Hello Michael,

i will try theses steps mentioned in note 1780896. Thank you.

In advance:

I have a legacy System (State of mid 2015) in which access type F still works with SAPLPD. And I just did a test print on a 6200 pages spool. Result: 29 Seconds (as mentioned in SAPLPD log)

Then I tryed the same amount of pages in our development System with Access type G. Result: still counting up that pages in Windows print Screen. It will take more than an hour until pdfcreator will appear on Screen.

Greetings

SL

[former_member59207]

update: i tried your steps.

could that error line be the cause?

after that he basically is just counting up the pages. The first at 15.41.01 went fast but after that hes counting up very slowly.

[michael_szardenings]

You can ignore the error line. It just says that you don't have PDFPRINT installed.

The PDF Creator needs 2 or more seconds to create one page. That's the printer driver.SAPLPD don't offer so much logging. However if you can connect to your legacy system from the same PC you did this test you could compare directly.

The G processing is attached to the SAPGUI process. Therefore if you close the SAPGUI window also the printer driver stops working. That's the reason why it stops after you close the window.

As mentioned the virtual PDF printers on Windows are all slow according to my experience. If you really just want a PDF you could try the PDF download Laszlo mentioned or use a device type PDF1 in the SAP system and an access method G printer with the Windows built-in port FILE. Then the PDF is created in the SAP system and you will get a file save dialog to save your PDF.

[jude_bradley]

Hello Sven

Access Method G was never intended for use for bulk printing, but just casual printing from the front-end.

Please be aware that SAP front-end printing is not designed for mass

printing or large documents or any critical printing.  Please see the

following note 128105 and test if the print works correctly with

access methods S, C (Windows) U or L (Unix).

  # 128105 - Front end printing (collective note)

   c) Restrictions

      Since front end printing uses the local GUI connection, it is

      generally unsuitable for the output of large or particularly

      time-critical documents.

https://service.sap.com/sap/support/notes/128105

Regards,

Jude

[former_member59207]

Hi Jude,

thats true but with Access type F it worked just fine. And I just dont understand why it doesnt work with Access type G anymore.

I mean under type F i was able to print out 3500 pages in just 35 seconds. Now under type G (or F) the same step takes me like hours

Greetings

SL

[jude_bradley]

Hello Sven,

Maybe note

https://service.sap.com/sap/support/notes/2028598

can help,

Apart from that, we really recommend using a different acess method, as bulk printing from the GUI can cause application crashes.

Regards.

Jude

[christoph_ostrop]

since that Change form saplpd to printing with control-technologie

we got that issue not only with bulk printing,

the issue is also with a few number of pages (less than 10), mostly with 1 or 2 pages.

[christoph_ostrop]

Hi,

we got also an issue with SAPGUI 740 frontend-printing, and hanging SPO-Workprocess (for frontend-printing)

have a look at sap-note 2028598

this is a workaround to use "F" again (after installing that correction of that sap-note)

http://service.sap.com/sap/support/notes/2028598

HTH

[former_member59207]

Hello Christoph,

we already implemented that note (Version 18, but i just saw there is a Version 23 out). But still no improvement. Did I miss something?

Greetings

SL

[christoph_ostrop]

we did same, have had installed a former version of that note,

in the actual version there is some additional coding included, so you should have the latest version of that note.

but the issue is not solved yet. we are just investigating ...

[Laszlo_B]

Hello Sven,

third-party PDF converters can be actually avoided with the R/3 PDF-conversion methods: R/3 can convert the spools into PDF format, which just needs to be saved on the frontend.

See SAP KBA #1580639 - "Is a PDF software required in windows for PDF conversion via device PDF1?" for details.

Best regards,

Laszlo

[former_member59207]

Hi Lazlo,

thank you for the hint on that note. I just gave it a try on a 1000 Pages spool. it´s faster but still takes a very Long time...

In comparison: I have a legacy System here in which I can use Access type F (saplpd). A 3500 pages spool just took 35 seconds. I Need to know how I can get that Performance back.

Greetings

SL

[Laszlo_B]

Hello Sven,

Jude is correct: processing a large volume of spools is not recommended for frontend. I know this won't answer the initial problem, but in the long term, 1000 pages can not be ensured to be processed without disruptions.

About the initial problem: in transaction SP01 display an example spool. Double-click on the spool's status, then in the new list click the checkbox on the left. Now press button "Output request status".

In the new popup select the button "Events". Now the timestamps of this spool will be shown.

It's a bit tricky though: they have a bottom-up structure.

Do you see any malfunctions here?

Also: others seem to promote SAP Note #2028598, which won't solve the problem.

Technically what this Note does is replacing Access Method F's internal workings with Access Method G.

This will mean that although in the backend you will select / make everything with Access Method F, the spool will be sent with Access Method G's functions.

Best regards,

Laszlo

[former_member59207]

Hi Laszlo,

thank you for your help.

Here are the timestamps for a 3500 pages spool via Access type G:

SAP says it´s finished. But in Windows Printer i can see the pages counting up:

The first 25 pages took about 1-2 sec. After that Initial Speed: 1 page per second

When I close SAPGUI now, only those few pages will be saved that have already bee processed.

I know frontend printing is not meant to be for mass processing. But I am just wondering why Access type F is so much faster.

Greetings

SL