Simulation of SAS program execution in SAS server

[BigSASFan]

We have around couple hundreds of users running on SAS server (on Unix). Usually there are around 200 ~ 300 SAS sessions running concurrently. Most programs run via interactive EG (Enterprise Guide) sessions (though they are production programs, these SAS programs run in interactive Ad-hoc way). Only a small portion SAS programs (10% ~ 15%) are scheduled from Unix cron.

Recently we installed a new SAS server, and is still in testing stage.

Since our SAS users are busy, we don't want to bother them to interrupt daily work to run their programs on the new SAS server, which currently is still in testing stage. I try to develop a wrapper program, and from within this wrapper, the SAS programs could be launched to run in the new SAS server, so as to simulate our users' daily activities. The whole purpose is to find a way to simulate some real programs execution in our new SAS server, and observe the server's performance, to make sure the new server meets the performance requirements.

As we have noticed in the current production SAS server, the number of SAS sessions follows some pattern: the number of SAS sessions start small at the beginning of the morning, and increases in the late morning when more and more SAS users start their daily work by running their programs via Enterprise Guide, the SAS server load peaks around 10~11AM, then drops during the lunch time, and peaks again around 2 to 3PM, and drops after 4PM. So it's like 2 normal distributions.

I have been developing a simulation program, and have made some progress. If anyone could give ideas or suggestions, e.g., example programs, blogs articles, SAS papers, etc., regarding how to to better write such a wrapper simulation program, I would highly appreciate.

The simulation program does not need be perfect, since I am not doing scientific research, but just to collect some performance information of our new SAS server.

Thank you!

[SASKiwi]

Personally I find bench-marking a few typical programs a good way to test new SAS servers performance. By running the same jobs on both existing and new SAS servers you can get a pretty good idea of the performance difference. It is a lot easier than a simulation approach and at the same time you can check out whether you get the same results or not. 

[BigSASFan]

---

@SASKiwi wrote:

Personally I find bench-marking a few typical programs a good way to test new SAS servers performance. By running the same jobs on both existing and new SAS servers you can get a pretty good idea of the performance difference. It is a lot easier than a simulation approach and at the same time you can check out whether you get the same results or not. 

---

Thanks for the input. That's a great point. Actually I do have some typical "real" programs for testing. I wish to combine the real programs with the simulation, for example, in the simulation script, we could launch these typical SAS programs at different time slots. Any thoughts are welcome?

[SASKiwi]

Well, I would still suggest bench-marking some test programs first. For example I did that recently myself with a new SAS server and to my surprise found that the server we were planning to migrate to ran jobs slower than our existing server. If this happens then I see no point in running any simulations because I know they are going to be slower anyway. In our case we decided to upgrade our existing server rather than move - we were lucky to have a plan B!

The best thing to do then is to find out why it is running slower. I see no point in doing simulations until your new server is running optimally. If you have already done this then that's great. Doing simulations would then make sense. I suggest running a series of batch jobs via a scheduler would be a good way of simulating. You could run a series of jobs simultaneously - say start with 1, then 2, then 4, then 8 and so on to see how it performs under load. I don't see it is necessary to mimic your current load over the day. I think it would be more important to see how it performs under the expected maximum load. For example if you get no more than say 30 simultaneous SAS sessions running at peak periods then run 30 batch jobs at the same time and see what the performance is like. 

[s_lassen]

While checking the performance of singular "typical" jobs may shine some light on the capacity of the server, what really matters is how the server stacks up when many processes are running in parallel. So you would probably want to start a number of jobs simultaneously, and check how fast it goes with different numbers of users (jobs). You may want to supervise the performance on the server at the same time - use the "Resource surveillance" or what ever it is called (running on a Danish version of Windows right now) in the bottom of the "Performance" tab in the Windows job list (which you get by pressing ctrl-alt-delete). One interesting measure is the number of "Page Faults" in the Memory tab - if you have many of those, you are running short on memory. Another is simply checking if the CPUs are working full out, or if disk performance is limiting the speed of the server.

I think you can run the tests by setting SAS/EG up to run in parallel, import varying programs (and varying numbers of them) to different process flows, and then run the various process flows one by one (or all of them with "Run Project"), and see what happens.