 Hello and welcome to this lecture in the course on Introduction to Computer and Network Performance Analysis using queuing systems. I am Professor Varshaapte. I am a faculty member in the department of Computer Science and Engineering IIT Bombay. So in the previous lectures we were looking at closed systems and just like we did for open queuing systems, we are going to go through a real measurement study of a web server. So this is again a recap for you to just look at all the formulae of the closed systems that we studied. We have studied low load asymptote for when number of users or clients is going towards 1. Then when the number of clients goes towards infinity and then for in between the asymptotes, these are all the formulae. Just a reminder that in the case of non asymptotic matrix, we do not know yet how to calculate each of these independently. These are all interrelated. So for example throughput is in terms of R and number of servers also in terms of R and response time is in terms of throughput. So look at these, these are interrelated. We do not really know how to calculate them independently, we are going to learn that later. But today this is all we know. So again like recall the earlier lecture with where we had done this measurement case study of a web server, the setup is identical in terms of what is going on at the server. There is a web server which has multiple processes or multiple threads in one process. It runs a CPU bound script and there is a client server where basically multiple threads of this load generator software generates requests. Now the difference is earlier requests were just generated at a given rate. In the open system, when we were having open arrivals, requests were getting generated at a given rate. So this is no longer the case, now we are looking the studying flow systems. So these threads behave like users who are in the think and issue request loop, the loop that we talked about in flow systems where the users are going to think for some time and then issue a request. So this is exactly what the clients here are going to do, they are going to issue a request, get a response and then think and then issue the request. So now there is this think time. So the way we give specification to the load generator is we give this number of users, we denote by m as usual and the think time h and that is used as input by the load generator and each of these threads is doing this request response loop. So the execution time of the script just like we saw in the previous open experiment is approximately 50 milliseconds, there is one core and one thread at the web server just to keep things simple and this is the experiment is happening on the LAN, so we do not have to bother about or worry about network delays. So this is just a table for your reference for all the measured values, we may look at this table every now and then but this is mainly for you to see after the lecture what the values are of the experiment. So as we had done again before we will start with trying to figure out based on what we know about the system, can we draw the throughput graph with respect to varying load, here it is going to be with respect to m, can we draw the graph ourselves, what can we draw, what can we say about the drafts given what we know about the system. So remember we know that the tau the execution time is 50 milliseconds that means the mu is going to be 20 requests per second, this is going to be the maximum capacity throughput capacity of the system and also remember that we have studied the Klein rock saturation heuristic which is 1 plus think time divided by service time and that turns out to be 41. So using these two things we should be able to draw something about the graph, so let us try here this is throughput, this is m. So one thing is that since I know that the saturation is going to happen around 41, so I should not draw the graph that much beyond 41. So let us say we just draw till around 100, so this is 50 and this is requests per second we know the maximum here is going to be 20, so this is 10, 5, 15. So somewhere here this is 25, 12, 6, somewhere here is 1. So one thing we know that around here is where is m star 41, somewhere here the throughput is going to start going towards the maximum not exactly here but we can be sure that around here the throughput is going to be for 20 requests per second. So we also know actually the throughput when the low load asymptote remember we know this 1 over h plus tau, so what is 1 over h plus tau here? It is 1 over h is 2 plus 0.05, so 1 over 2.05, so it is almost around 1 over 2, so 0.5. So here we can say that the value at 1 is going to be around 0.5 requests per second, 1 over 2.05 is almost going to be equal to 0.5. So we know the value at 1, we know the maximum value and in the middle we do not really know remember that the middle values need this R and we do not really know that. So we can guess initially that it is going to remain low, so we can guess that when m is equal to 2 this is going to be 1 and so on but otherwise we just sort of heuristically connect this graph like this and this is what we expect that it is going to be. So let us see now the actual graph, the maximum here is very close to this is 20, it is very close to what we predicted theoretically, rest of it as I said we do not really have a handle on it. At 20 we are getting around 9 requests per second. If we take, remember the value here, m divided by h plus R let us put this for 20 and see what happens. So for m equal to 20 we have 20 divided by h is 2 and R we do not know but R we can maybe guess that it is going to be around not that much more than 0, what if it was 0.05, what if it was 0.05 we would get 20 divided by 2.05 which is around 10. So if the response time remained so low, if the response time remained close to tau, then actually we expect that the throughput at 20 when there are 20 users in the system would be 10 requests per second. That would be our expectation which is what this calculation is showing and it is very interesting to see that it is around it is close to 10. So even if we did a calculation assuming that R is close to tau, tau here is 0.05 in seconds, we get a close enough prediction to the actual value. We expect that it would not be 10 it will be something less because R will actually be greater than tau, it would not remain 50 milliseconds and therefore this will actually be less than 10 and we get around 9. So it is nice to see and you should try to do these calculations and predict actually this graph not only at 1 and at infinity but even at the middle points it does make sense. So now let us go to utilization, similar things can be done for utilization. Let us draw the graph. Now this is rho, it is going to be between 0 and 1. Again let us just draw it for m till 100, this is 50, 25, somewhere here is m star, 41. At somewhere around these points we know that utilization is going to be 1. In fact the nature of the utilization graph will be very similar to the throughput. So at m equal to 1 we can actually calculate utilization. What is the m equal to 1 utilization? We can look at this, utilization is going to be tau divided by h plus tau. Basically one user issues a request every h plus tau time and in that time or out of that time tau amount of time the CPU is busy. So that is going to be the utilization. So rho at 1 is basically 0.05 divided by 2 plus 0.05. This is basically 0.05 divided by 2.05 which is going to be very close to 0.05 divided by 2. So let us just do that calculation. This is 0.025 close to that. So that is our estimate here for m equal to 1, 0.025. In reality it might be turning out to be almost 0. So we start from there and again in the middle we have some values. Again they depend on R. Just because throughput depends on R, utilization also has R in it. So we cannot really calculate it exactly. But let us look at what the actual graph was and let us see whether the graph made sense. Again it is pretty perfect. And we can see by the way both in the throughput and the utilization chart this part at around 41 is where you do start approaching the high values of utilization and then it starts approaching saturation. And if you recall how Klein Rock heuristic is derived, it is actually trying to predict exactly this point. It is not trying to predict the full saturation point, it is trying to predict the approaching of saturation. So it is not bad. It is our prediction of 41 was pretty good. Now let us do the same kind of reasoning for 20 users. Now we actually know the throughput. So at 20 we know that the throughput was around 9. So if we know the throughput, can we calculate the utilization directly using utilization law? So suppose it is 9 requests per second. So at rho at 20 is equal to lambda at 20 multiplied by tau throughput at 20, which was 9 multiplied by 0.05. This is 0.45 approximately. Let us see what we get here at 20. So very close. This is 0.5. So little less than 0.5 is 0.45. This is exactly what one would expect just by utilization law. I would encourage you to do the same calculation at other numbers. So this value here should be equal to throughput at 30 multiplied by 0.05. And I would encourage you to do the calculation and see whether you get some number that verifies this number. But clearly even utilization graph matches our predictions well. We can look at 10 because some nice number 0.25. Let us see what happens at 10. At 10 throughput was 5 requests per second. This is 5. This is the point we are looking at. So throughput was 5 requests per second. So let us do the calculation here. This should be throughput at 10 multiplied by 0.05. This was 5 multiplied by 0.05, which should be 0.25 and lo and behold that is exactly what we get. So it is matching very well. The utilization law is a very, very powerful law. It will apply very, if it does not apply that should be an indication to you that something is very different in the system. Again either there is a measurement error or you are not modeling something about the system. So these kind of sanity checks to see whether whatever I have learnt as laws in my theory are they applying when I do this measurement. This helps in either confirming whatever you expect or pointing out that something is different or wrong about your experiment and it is not matching the theory. Now let us look at response time. Remember at response time at 1 should just be equal to tau. So this is 0.05 or 50 milliseconds. And response time asymptote, we had done this in our closed systems. It is remember m, actually m tau minus h. This is at any value of m and the asymptote is m tau minus h. So what is it going to be here? That asymptote will be so r m will be m multiplied by 0.05 minus 2 for large m and especially for m less greater than let us say 50 also. We know what is large for this system. Anything after saturation is large. So 41 is where remember m star is 41. 41 is where the knee of the curves are. 41 is where saturation is approaching. So beyond 41 we have seen here at around 50 or 60 and onwards system is definitely getting saturated is going to 1. So we can say that 50 or 60 is after which this particular formula for response time should apply. So we can draw the graph accordingly. So let us do that. This is r, this is m. Again I am just going to draw 150, this 75, 25, 12 somewhere around 1. We know that this should be, if we are doing this in milliseconds then it will be some 50 milliseconds and let us plug this in for at 60 and see what happens. So if it is milliseconds then r 60 is going to be 60 multiplied by 50 milliseconds minus 2000. So this is actually 3000 minus 2000. 1000 milliseconds. So on 60 let us say this is 1000 and that is what this value is going to be. But what is going to be the shape? Remember that response time is not going to flatten. It is going to have shape like this where this part is linear and the slope is going to be tau since we have, so which is 50 milliseconds. The slope should be 50 milliseconds because r at this point is equal to m tau minus h, tau is the slope. So we have made our theoretical graph, let us see how it matches with the actual measurement. So let us check at 60. So this happens to be in seconds. This is seconds. Remember we had done r 60 is 1000 milliseconds which is equal to 1 second. So let us check here at 60 it is actually exactly 1 second. And again at 41 is where the knee is happening. Remember the Klein-Roch saturation heuristic was made by doing this meeting point of the low load asymptote and the high load asymptote. And this is exactly what is matching here and the saturation heuristic really turned out to be perfect for this. We can actually also do the same calculation for m equal to 100. This is just showing this graph on a larger scale here and in seconds. So let us do this for m equal to 100. So r 100 is equal to 100 multiplied by 50 minus 2000 in milliseconds. So this is 5000 minus 2000. So this is 3000 milliseconds. So let us see what it is here. So yes. So this is where we are finding. So exactly 3 seconds is what we are getting in the measured value. So really the theory that we learned for closed systems seems to be matching our measurement quite well. And so again if it did not match we will have experiments where it does not match. And that should make you just think as to what is different about your system. It may not be wrong. It says that it may not be as simple as the kind of closed system that we are modeling in theory. But it will help you find the differences. This is an interesting graph which is showing response time versus throughput. So we do something like response time versus request per second when we did graphs for open systems. But in that case the arrival rate kept increasing. Here what happens is beyond a certain point the throughput is not going to increase. The throughput flattens out at 20. So if we see that response time is like a impulse function where at the same value of throughput it just keeps increasing. So this is a very interesting graph to see. So there is a sharp rise because you are never going to get a value of throughput higher than 20 because that is just the maximum capacity of the system. Whereas response time keeps increasing. So it is sort of like having many multiple values going on increasing for the same x value. Utilization versus throughput actually because now by utilization law this should be a proper line. Remember that when you look at utilization versus number of users this is not a graph that is supposed to be actually linear. This part the slope is not expected to be tau. The slope is expected to be tau only when you plot it against throughput. So that is what this is doing. This will actually be tau because rho is equal to throughput multiplied by tau. And you can check this yourself whether you are getting. So for value 10 you can of course see 10 multiplied by 0.05 is equal to 0.5 and that is what you get here. So this is clearly just a straightforward application of utilization law and this is what is expected. We can do one more check actually for the response time versus number of users. This slope is supposed to be tau. We can check whether the slope is tau. So at 100 for example we had 3 and at 80 we had 2. So 3 – 2 divided by 20 or we can say so this is 1 divided by 20 in seconds. So that is 1000 divided by 20 milliseconds and this is 50 milliseconds which is exactly our tau. So that is also matching. So one more very interesting thing we can do for closed systems which is a sort of a think time verification. So by Little's law we should have for any low level this formula. Again m is equal to R6 plus h which is think time multiplied by throughput. If we rearrange this we can have the think time on the left hand side and this formula on the right hand side m by throughput minus R6 the response time basically. So if we use this formula and calculate think time for every value of m we should just get 2 seconds. So this also turns out to be a very good sanity check of your experiments and the next table shows that this has been done for each of these values and this is the think time which is calculated based on these values by the m divided by lambda minus R formula. So this is the m, this is the throughput and this is the R6 and this is the formula that is being used for calculating this. So these values should all be close to 2 seconds and if you look at them they are fairly close to 2 seconds. Now why do we do this calculation? Sometimes think time gets inflated. You configure 2 seconds but you are getting like 5 seconds, 6 seconds and sometimes this really means that there is some other time in the system that you are not accounting for. Sometimes it means that the client is bottlenecking and when this check fails this is a big indication that something is wrong with your experiment and you need to make sure whether your model is correct, your experiment is correct and so on. So this is a very again another case study of how you could use queuing systems formulae and compare them with what you are getting in measurements and in this particular study that we did this experiment the match was actually very good and often when in closed systems in some systems you can get a very good match. We are done with like closed queuing systems with just one node just like we did open queuing networks and there were multiple nodes and where request flow through various nodes we are going to next do closed queuing networks which is also the last topic of this course. Thank you.