So we have created some scripts that will show us our possibly concurrency, but what does this mean and how do we work out how many session engines we will need. This article will explain, what a session engine is and why we need at least one of them. We will show you some test results that we have run with the Data Collection Load tool and some standard scripts.
So what is a session engine. Well a Session engine , in simple terms is the program that presents your survey page to the respondent and then takes the results and passes the information back to the rest of the system. The session engine sits inside of an IIS application pool, and for those of you that don’t know what that means , lets explain. IIS as we should know by now is Microsoft Internet Information Server, and it is the program that allows us to host our WebPages on a windows machine. Before Application pools where designed an IIS machine could have many web applications running on it , and if one of those applications was to crash it could infect and bring down the entire IIS machine and stop all programs from working. With the introduction of application pools , the idea is that each program has its own application pool and if something goes wrong then it is only the apps in that pool that will fail. Everything else on IIS should remain active.
When using Data Collection we recommend that you have 1 session engine for each gig – 1 of memory that you have on the IIS box. This means that if you have a 4gig IIS machine you should have 3 session engines , leaving 1 gig of memory for the machine its self. When you have more than one session engine on a machine , as it gets stressed or overworked with too many surveys using it , there is a load mechanism inside of Data collection that will start to move new surveys onto the other session engines so that the load is spread and the IIS machine can take more surveys or concurrents.
So how many concurrents should a session engine be able to hold. This is actually harder to work out that you might think because each survey is different , and by that we mean it has a different number of questions that are of many different question types. Some surveys will have lots of graphics and perhaps use quotas and sample management so you should be able to see that it is very hard to predict an exact number , but we can do some things to guess what the level might be.
So how do we come up with a number , well ,in the DDL there are three surveys and what we did was to take these surveys and set them up in a 5.5 environment and run some tests using the load tool that comes with interview server. The load tool allows us to pretend to be a certain number of respondents running surveys. With this tool running what we did was to record the memory usage of the session engine , resetting it to zero for each test and then entered the information into excel to come up with some numbers.
Firstly let’s look at the MDD files themselves. We have three , and these are their stats,
| Name | Size in K | Variable Instances | Number of Questions |
| Small | 9118 | 329 | 57 |
| Medium | 1218 | 1529 | 273 |
| Large | 1838 | 5029 | 553 |
The small survey you will notice is bigger than the others , and this is because it has 2 versions in it. At this stage , we did not change it , but as we plan to run these tests on later versions we will make sure that all tests are done with the same number of versions in them. At this you should note that we did not add any quotas or sample managements to the test, we just wanted to record some numbers to see what we can do with them. So what tests did we do?
The first test was to run each survey with “One Concurrent” for 30 mins and record the memory usage, these are the results.
| Name | Duration | Memory Used(k) |
| Small | 30 | 11496 |
| Medium | 30 | 21840 |
| Large | 30 | 38596 |
When using the load tool you have lots of settings to play with, that will influence the number of final completed surveys. We just took the defaults , and then by looking at the data we worked out the following information.
| Name | Total Starts | Total Comps | Variable instance with data |
| Small | 18 | 18 | 200 |
| Medium | 4 | 3 | 996 |
| Large | 4 | 3 | 3096 |
Taking this information we can work out that 1 question takes up the following amount of memory,
mem = Number of Questions / amount of memory used.
So this means,
| Name | memory for 1 question(k) | memory per respondent (k) |
| Small | 11.2 | 638.7 |
| Medium | 20 | 5460 |
| Large | 17.5 | 9649 |
So , does that mean if we have 25 respondents for the same duration we get a number that is 25 times as big as the number above, let’s see. We next re-ran the tests , but this time we upped the concurrents to 25. And the results where ,
| Name | Duration | Memory Used(k) | Starts | Completes |
| Small | 30 | 43324 | 416 | 407 |
| Medium | 30 | 97894 | 101 | 76 |
| Large | 30 | 151868 | 121 | 96 |
which results in the following per respondent
| Name | memory for 1 question(k) | memory per respondent (k) |
| Small | 1.83 | 104.144 |
| Medium | 3.6 | 969.247 |
| Large | 2.26 | 1255.107 |
You might think that this is strange memory usage per respondent, but one way it can be explained is that as Data collection starts to use memory for the second and subsequent surveys it re-uses some of the memory that is already taken. This makes the session engines faster than normal, and its better programming, why load something up again , when it is already there.
Next we took the test up to 50 concurrents and noted the results, we ended up with the following results.
| Name | memory for 1 question(k) | memory per respondent (k) |
| Small | 2.24 | 128.056 |
| Medium | 4.47 | 1220.72 |
| Large | 2.67 | 1479.743 |
so now we can see that memory usage is slowly on the UP and this is probably not what you would expect, but if you think about things like memory leaks , coding that does not clean its memory up quickly enough, then you can understand why this might be.
So is this data any use, well like everything , the more data you have the more accurate your results will be , so we could go on and on and keep upping the load tests and see when a session engine final reaches its maximum load , which by the way can be defined , but by default we have around 800mb of that 1 gig to play with. So how many of each of the surveys can we host on one session engine.
To work this out , what we are going to do , this time round is to use the following equation
1 survey memory usage = (( 50 concurrents memory - 25 concurrents memory ) / 25 )
This works out to be for 1 survey
| Name | memory per respondent (k) |
| Small | 2948.8 |
| Medium | 3701.52 |
| Large | 4993.76 |
Then we take this number and using 819200 as 800mb ( in k ) we can work out that the maximums could possibly be,
| Name | Max Per Session Engine |
| Small | 277 |
| Medium | 221 |
| Large | 164 |
so what does this tell us , well , we are yet to prove this , and we probably will not for version 5.5 , but will do it for 5.6 in the next article on this that if your survey has the similar characteristics as the small job , then in a 30 minute duration the maximum concurrents you could have on one session engine would be arround 277.
Now we are sure that some of you may not agree with the way we have calculated this, but it’s a start and as we re-test for 5.6 then we will begin to be able to refine this process and get a better handle on the real numbers.