 Here I have Divakar Thammishetti and Sumant Poli as my team members. Today we stand before you to present our project on optimization of CYLAB instances on server. So this is brief outline about what we will be speaking here today. I will begin with explaining about the existing CYLAB on Cloud website. Then why we need to optimize that website. Then I'll speak about our proposed solution. Then Divakar will explain the implementation details and the workflow of our solution. Then Sumant will discuss the test results. So this CYLAB on Cloud website, this was implemented by Fawcys people here at IIT Bombay. So basically as the previous team spoke about CYLAB textbook companion, so a user can select one of the examples using those drop-downs, or he or she can enter their own CYLAB code and execute it. So this website has been hosted on Django framework. So whenever a user hits on the execute button, this particular code is sent to a Django server. Then the Django server spawns a CYLAB instance, the CYLAB ADV CLI interpreter to be in precise. Then that interpreter, it executes this code and the output is collected. Before the output is sent back to the user, the instance is skilled. So whenever a request is sent, the same process repeats. So the actual problem occurs when multiple requests pour in at the same time. Since server has a certain hardware capacity, and each CYLAB instance requires around 100 MB. So we cannot indefinitely spawn CYLAB instances if many requests pour in. So if we look at the overall response time, it includes the loading time of CYLAB interpreter. Then the execution time, then there is also this network latency factor, and we also have waiting time in the case where there are a lot of requests coming in. So what we have done as a part of optimization is, we have eliminated this loading time, and we have reduced this waiting time factor also. So how we achieve this is by, instead of killing the CYLAB instances soon after executing the code, what we have done is we have kept it alive in the background, and as soon as any user request comes in, we just feed the code, collect the output, send it back to the user. And in our solution, it is also able to handle multiple user requests because we are using Tornado, and it has this feature of asynchronous and parallel execution. So, Divakar will now explain the exact details of our solution. Good evening everybody. Coming to the implementation details of our project, the major challenge in our project is keeping the CYLAB instances alive in the background. For that, we have used PXPECT. PXPECT is a Python model, which is used to spawn the CYLAB instances in the background, and we can interact with the child by sending the data and expecting some responses. And another major challenge in our project is allowing multiple user access. For that, we have used Tornado, and Tornado is a scalable and non-blocking server, non-blocking server, and we have used multiple threads to allow the multiple users access simultaneously. Coming to the workflow of our project, first, as we know that in the existing CYLAB on Cloud Function, in the website, the user is allowed to select any one of the examples from any standard textbook, or he can write his own code. And in the next step, when he enters the execute button, and the code will be including data and token, some other parameters will be sent to Django server, and from that, we are sending an adjunct request to Tornado. And in the Tornado, we have written asynchronous handler, and which will give the request to one of the worker, which is run by a thread. And we are returning the control to the event loop, which is run by Tornado's to listen to other controls, to listen to the other requests, so that we can allow multiple requests at the same time. And we are maintaining some pull up CYLAB instance in the background. And whenever request comes, we are using one of the free CYLAB instance to execute the code. Once we execute the code, we'll put again in the list, and we return the result to the Django server, which will again be displayed on the browser. Next, Sumant will continue the test results. Good evening all. Now we are going to demonstrate our project. On the screen, you can see two sites. There is Dev1 and Dev2. Dev2 is the duplicate of globally and currently existing CYLAB site. That is dev.4c.in. Dev1 is the replication of our project. Let's test these two sites by giving identical inputs. Yeah, 830 is Dev2. Let's execute it. Observe the time difference here. Yeah, this is a graph code in chemical and chemical engineering department. And execute the same code in Dev1. Yeah, you might have noticed one thing that execution time for Dev1 is taking less time than the Dev2. Let's confirm it again. This is Dev2. Old implementation, which is currently existing in CYLAB now. It is taking some time. This is Dev1, which we have worked on it. And as we calculated in the lab, enumerated time duration for Dev1 is... Yes, you can check it here. Enumerate it. Do you see our result? Ah, there's no... Go to the next one. Next one. What is the details when you get out? Same. I don't know. What is different? It is quite faster than Dev2. What are the numbers are there? I am not going to look at the graph. Okay, just... 1.2, 1, 3, 5, 1, 3, 4, 2, 3, 9, 7, 5... No, it is an output. It is the result of the question. It is the output of the program. Yeah. It is the output of the... It is the output of the program. Yeah. No, we tested it in the lab. And we have a table in the PPT. We will show it later. You can have a table in the program. You can have a table in the PPT. Right? Yeah. I say, I am going to execute on server 1. I am going to execute on server 2. And you are showing me nothing. Sir, you have to run the same code for the comparison. Right. You can feel it, you can feel it right now. Right. That is not work. So, practically having the softwares and then fixing it because it is a matter of... That is not the way to test. Come on, please. Sir, when we practically tested, we had a mobile... Why don't you run the same thing 100 times and then check? When it is 5 minutes or something, I will accept. 4 seconds and 4.23 seconds is no appreciable time. Anyway, it doesn't matter. Go. I will let's assume that you are faster. Go. Sir, because these scripts are not very long. They are short codes and execution doesn't take a very long time. I don't even know what it is. If you give me 5 minutes, I will make it 100 times. By just looking at the code. All I need to repeat it 100 times, it will take 100 times more. Whatever it is. Okay. I will do it without knowing the language. But that doesn't matter. Let's assume that you have done it. Proceed. Your thing is faster. Understood. Agreed? Sir, we tried around 10000 lines of code, but for the demonstration problem, we don't know. No, that's okay. I agree. Go ahead. Don't show it to anyone. So, since we are not going to these tables now. I believe you. I am not saying you are lying. I believe you. But you have not proved it. There are two different things. Trust me. It's different from... Here it is. That is different. Okay. I am saying you are not proving it. Go ahead. You are not proving it by showing me those two servers. That is not proof. This is okay. Go ahead. Now, implementation of this project is achieved in two stages. In stage one, we kept all Sylab instances. I don't agree that you can prove it this way. Because the way you are getting better time, according to your claim, is you are saving the load time. One time execution does not save any load time. Again and again inside a loop. Then you will get a better thing. Go ahead. Improvement of this project is achieved in two stages. In stage one, we kept all Sylab instances available in the backend. So that loading of all Sylab libraries for each request is being avoided. In stage two, organization of all these Sylab instances is made dynamic. Means I am spawning the Sylab instances based on the business of the server. Let's take an example. There are four instances out there in the Sylab server. And four Sylab instances are engaged with each different request. Means four Sylab instances are busy. I am spawning. No, four Sylab instances are serving. Means at a time, a server can serve four requesters. And four requesters came. And these four Sylab instances are serving those four requesters. Now a few, a next Sylab instance came. That's let's say fifth one. And now since these four Sylab instances are busy, I'm going to spawn a new Sylab instance. And assigning that Sylab instance to this request. And now I have five Sylab instances in my server. At a time, I can access five Sylab, five requests. Now a sixth request came. Now I'm going to spawn a new process. If any of these Sylab instance free, I'm going to assign these Sylab instance to this request. If not, I'm going to spawn a new Sylab instance. And assigning that Sylab instance to this request. And this process goes on to a certain level, certain limit, fixed number, where server can bury, bear all these Sylab instances. Okay. Actually asynchronous networking library. So it uses threads for execution. It has this IO loop. Since it's asynchronous, what happens in asynchronous is, it doesn't wait for a task to complete. So it can always initiate another task without completing the, spawning the new process is done by PXPECT. So listening to the request is done by Tornado. So we can have multiple requests. So PXPECT is just like a container around the Sylab instance. What program Sylab has is, it has different modes of operating. So what this existing Sylab on cloud instance does is, it executes it in the file mode. So we can directly state in terminal with a dash f flag and we state the file name. So it will execute and produce output, but it won't be able to execute the next file. But if we use PXPECT, if we spawn Sylab instance through PXPECT, we can execute multiple files using the same instance. And since we are not here, the load time is not included. Execution time is the only factor here. It's a module, Python module. It's similar to Dawn Libs expect. It was meant for Unix-like system. So they, Python people, they came up with this PXPECT and it's for this automation purpose. You want certain like SSH and all things are there. You don't want to personally sit and type out everything. So you just can write a few lines, automate everything and wait for the result. Let me continue. After spawning all Sylab instances, and suppose if there are no users are accessing the site, means spawned Sylab instance are free now, means they are not working. In that case, there is instance manager, which is an infinite thread running in the backend and the lifetime of these Sylab instances is decided by this instance manager. Yeah, this infinite thread is written in the tornado site. Since tornado is infinite, infinitely running. Yes, it keeps several, for infinite time. Ah, it's simply a process. Okay, this infinite thread, what it actually does is for each interval of time, it checks how many instances are actually working in the server. How many instances are actually working and how many instances are not working and then it is going to kill the instances which are not working. And this process goes till there is a single request, single instances, alive in the server. We are assuming that any user can access any time. So we're keeping one instance alive. It's all is under our control. We can manage how many instances as we needed. Yes, we can. Everything can be done. Yeah, there is the exploitation of CP resources in server. So what is the point in not, in killing it ever? This skylab instance takes 100 MB of RAM. Fine. So if we span more. That server is only doing skylab, no? No, no. In server can exist any sites, right? That server asked a question about a particular server. Your server is only doing skylab, no? Yeah. So why not occupy all the instances forever? In that case we can do that. Yeah, correct. If the server is. In this case, this particular server on which you have executed your machine, that is dedicated to skylab, no? No. It's a dedicated server. We are not sure about it. You're not sure? You are not sure? A server can contain any websites, right? I asked you about one particular server. It can contain any website, it cannot contain any website, zero also. That does not matter. This particular server which you are managing, Dev1 or Dev2 or the production server, is it meant only for skylab? If it is meant only for skylab, I don't need to ever terminate anything. Okay. There's only one server on Garuda Cloud that is hosting this. Yeah, I need to only hosting this. Yeah, there's only one. So we would preferably want like. No, but it is only hosting the skylab site. So you can occupy all 100 megs as much as you want, permanently. It's a problem to keep it alive. Okay, so there's a reason. Correct, I was wondering why. Correct, correct. But they should know. Correct. Thank you.