Speed up the response time for proc greplay?

[alr]

Hi,

Is it possible to speed up the response time for a proc greplay?

F.ex. is it possible to index the gseg catalog?

My users are not patient   I show them more than 60 graphs in a dashboard from my gseg catalog using proc greplay and treplay.

The code is running on SAS IntrNet z/OS version 8.2 - the graphs are generated in advance (batch). :smileyshocked:

Thanks

[GraphGuy]

There are a lot of "it depends" ...

What device are you using? (gif, png, other?)

What fonts are you using? (software fonts such as swiss? or something other than sas/graph software fonts?)

How long is it taking to generate the graphs?

How are users viewing the graphs?

I would recommend upgrading to a newer version of SAS than 8.2 if at all possible (I recommend 9.2m3 or higher). In particular, you can get better-looking fonts (such as 'albany amt'), easier, and they will be rendered with freetype font rendering. Additionally, you can use those fonts (such as albany amt) on all systems (mainframe, unix, windows). Plus each version of sas has enhancements (including speed enhancements) and bug fixes in general.

Here's one font-related issue that caused slowness in certain situations in 6.x (and maybe 8.x). I recall that on a Unix sas/intrnet server, my graphs were sometimes slow. Turns out the problem was that the sas job was trying to query the Unix X-server to find out something about the fonts, and if the DISPLAY variable wasn't set to a valid display, then that query would 'hang' for several seconds. One work-around was to make sure the DISPLAY of the running sas/intrnet process was set to a valid display, and another work-around was to set 'goptions nocharacters' (but then you couldn't use any nice fonts in your graphs). 9.2m3 and higher automatically install & register some nice fonts (such as albany amt) during the sas install, and use freetype font rendering, and the unix sas/intrnet server no longer has the afore-mentioned problem. (I'm not sure if you might be experiencing a similar problem on the mainframe, but it sure seems possible!

[alr]

Thank you for your replay.

The system runs at mainframe and there are no plans to upgrade the system

I have two test codes one of them generate GIF and the other PNG.

PNG seems to have a better response time.

For both of them I use the font, swiss.

My Dashboard is built of 12 elements. Each element contains 4 graphs. So my template has 48 places.

All the graphs are pre generated (in batch job – using proc gchart, annotate etc.) and are saved in a permanent gseg catalog.

The only thing online program dose is to generate the template (with the 48 places) and bring the pre generated graphs from the gseg catalog and puts them in the right place (using proc greplay and treplay – device=PNG).

If we decide to continue in this direction I will off course save the template in library as well.

The response time for users varies from 4-8 seconds.

My question is if there are any ways I can access the gseg catalog faster (index, sort, compress…???)?

I have also thought to pre-generate the elements and in this way reduce the number og PNG files which will be accessed. But I’m not sure if that will give anything.

Each graph file is approximately 4.0KB (so I bring up 48x4=192 KB).

[ballardw]

Treplay the images to a different catalog or image file before the meeting and just show the resulting images instead of watching what happens with greplay perhaps?