 Good morning, everyone. First of all, I'd like to thank Professor Fatuk and Mr. Nagesh Karmali for guiding us and giving us this valuable opportunity to work on the fundamental research group project that is optimizing moodle learning management system to improve the user response time. Our project in charge is Mr. Nagesh Karmali and the team members are me, Priyanka Manchanda, Akshaya Muran, Surya Pratap Singh, Mevin Dominic, Shilpa Reddy and Shabna Tiyaar. So this is the agenda of our presentation. We'll start with the introduction to moodle and then we'll discuss about the front-end optimization techniques. We'll have a discussion on study of performance of moodle, backend optimization, hardware optimization, client server communication mechanism for moodle quiz plug-in and policy enforcement framework. So first of all, I'll discuss about the scope of the project. The Internet has seen growth in the number of web applications over the last few years. These web applications have now become an inseparable part of various industries like business, computing, education and telecommunications. So one of the major issues in these scenarios and the current scenario is to improve the performance of these web applications. One of the most critical factors is to improve the user response time. In a research study, we found that the delay of one second can reduce the customer satisfaction by up to 16%. So our objective is to analyze various optimization techniques and implement them for moodle so that we can use those optimization techniques for any other web application and optimize any web application. So here's a brief introduction to moodle. Moodle stands for modular object-oriented dynamic learning environment. Moodle is an open-source course management system which was developed by Martin Durgimas. Its first version was released in August 2002. It is used in various institutions all over the world to implement an organized interface for e-learning. These are some of the moodle statistics. There are about 83,059 currently active sites in 206 countries with 70 million users and 7.5 million courses and more than 1.2 million teachers. So this is the moodle architecture. The client and the server communicate using HTTP response, HTTP request. The server consists of Moodle LMS which is scripted in PHP 5. The database used is MySQL version 5 and the web server on which we have done our experiments is Apache 2.4. The operating system used is up to 12.10. Now we'll discuss some of the front-end optimization techniques for moodle. The front-end optimization techniques we are discussing are caching by using far-future Xpy headers, reduced DNS lookups, Gzip components, deactivating e-tags, and caching Ajax components. The browser uses cache to reduce the number of HTTP requests, to reduce the size of HTTP requests and thus make the web page load faster, thereby reducing the average user response time. Xpy's header is used to inform, is used by the server to inform the client to use the current copy of the component in the cache until a specified time. Now moodle's default Xpy's header is set in past, that is 20th August, 1969. We did changes in the httpd.conf file of the Apache server and changed it to 16th April, 2015, setting it in future. This is the experimental setup. We used one GB RAM on a 128 GB SSD. The processor used was i5. The experiment was done for the chat activity of moodle. The pages visited were login, view course, view chat page, initialize initial update, and these pages, initialize chat update were looped five times using a loop controller. So for one user and one iteration, we had 15 samples, and the test was done using Apache JMeter. These are the results of the experiment. We found a reduction of 74.14% in average user response time after implementation of this technique. Now the next technique is to reduce the DNS lookup. Now internet find servers through IP addresses. Domain name servers are used to map the host names to the IP addresses. The browser is idle until the DNS lookup is complete. So we did an experiment and calculated the difference between when the page is taken from the DNS cache and when it is not taken from DNS cache. Next. So these are the results we found. We found a reduction of 1.84 seconds in average user response time if the page is found in DNS cache. So then we did the same experiment for 100 iterations under three scenarios. In the first scenario, the number of cache entries are 20, and the cache expiration period is 60 seconds. The HTTP keep alive timeout is 115 seconds. Scenario two has cache entries of 512, and the expiration period is 3600 seconds, that is 1 hour. And the keep alive timeout is 115 seconds. The scenario three has cache entries of 512, expiration period as 1 hour, and the timeout is now changed to 0 seconds. So this is the result we obtained. We found that scenario two gave us the best results. So we can conclude that increasing the number of DNS cache entries, increasing the DNS cache period, and if a network supports HTTP keep alive timeout, can actually optimize model. The next one is Gzip components. Now a server can send, if a server sends the response and compresses that response, then we can optimize model. So to do so, the client sends the request with a header except encoding Gzip deflate, and sends back the server sends the response using the header content encoding Gzip. So this is the results we have. We got a reduction of 617.818kb in the size of the request after compression. Next technique is deactivating eTags. eTag or entity tag are used to identify a particular component. eTags are unique to a particular server hosting the site. So if a server first makes a request from one server and then makes a conditional request from other server, then the eTags are invalid. So if we remove these eTags, then we can reduce the response header by 48 bytes. Now this diagram shows the use of eTags. First the server makes a request, then the eTag is returned. In the next request, the server makes the same request. If the eTags match, instead of sending the entire data of component, it tells it that the component has not modified and the requested 304 not modified. Model uses a jack to modify data without altering the basic framework of the website. So by default, it is not cached. So what we can do to enable caching of the eTags component is initially enable eTags in model and just make a change in this file and update the expires header exactly as Priyanka had talked about. So this is the result that we got after updating the expires header. So as we can see the performance improvement is nearly 26.5%. Another study that we thought of doing was of model's performance with the default settings, I mean the default features used such as Apache HTTP server and PHP and MySQL database and of course study the bottlenecks. So we initially tested all the features using Jmeter. Jmeter has a default plugin for model. So this is the plugin. Using this plugin, we can generate load testing scripts for different activity modules in model. So we tested for these four modules, forum, quiz, chat and glossary. So as we can see quiz takes the maximum amount of time. So quiz seems to be the bottleneck in model. So from that point on we conducted all tests for the quiz plugin. So we tested for a quiz which has one question and these are the requests that were sent to the model server. So initially we use different timers to set the time interval between consecutive requests. So this was to determine the worst case so that in further testing scenarios, we could use the worst case timer. So in the results we obtained, we found that synchronized timer was the slowest and hence the worst case. Okay, then we wanted to study how the response time of model changes when we increase the number of users. So for this, we borrowed a pretty powerful server from the department. These are the features of the server which we used. It ran the default lamp server. And the ramp up period was one second because in real time when we simulate real time traffic, the worst case is that all the users log on at the same time or within a very short period of time. And number of loops forever because this simulates that all the threads are simultaneously connected so that few threads don't log off by the time others log on. So we test until we obtain this error because this tells us that the server is no longer able to handle any more requests. So we increase the users from 100. So this is a result we got. As you can see around 412, we started getting errors, which means this is the maximum that the server could handle. So it's an almost linear relationship. So we heard that YouTube, which has so much of traffic every day, does not actually use Apache or is or any of the popular servers. It uses light TPD. So we thought if we could test moodle with this server, probably we'd get a bet much better response time. And we did. So we benchmarked the moodle on light TPD server versus moodle on a Apache's web server. And we got a much lower response time for light TPD than Apache. So this appears to be a good way of optimizing. So now I'll hand it over to Surya. He'll discuss query optimization. Good morning, everyone. I'm Surya with AppSync. First of all, I will talk about the moodle table size problem. Moodle backup controllers is the biggest table in the database. Its size is around 1.6 GB, and it contains around 22.5K entries. So here's a simple script to delete the old entries over a week old, so that we can maintain the new entries effectively. Now improvement in the grading system. So whenever a module creates an instance of an activity, it uses two functions, the grader blade function and the grader item update function. So it sets the parameter for that activity. Now initially, suppose if we set the parameter to zero, then the grade type will be set to none. Then we can edit it and set it to a particular value. So it will set it to a particular value, and then it can be edited. Now suppose again, we set it to zero, then that zero activity will always remain in the module, and it can't be edited again. So we have to take care of that that once we set a value to it, we don't have to make it null again. So this will enhance the grading system of Moodle. So we have to avoid activities with zero grade. Now removing relevant links in quiz plugin. So like a plugin is simply a folder of PHP scripts, JavaScripts, and so on. So there's a file named lib.php in every plugin, and there are entry points in that through which the Moodle core interacts with the plugin. And the view.php controls the particular instance of the real-time quiz. So we have to make editing in that to control the view of the quiz. So we want that the entire control should be in the hands of the teacher and not the student. So I made some simple changes. I defined some global variables in the view.php file, and I initially set them to one. Then I control them by resetting the value to zero whenever the teacher starts the quiz or the student takes the quiz. So by putting the footer in the conditional loop, I control the view. Thanks. Good morning, everyone. I am Mevin Dominic. I'll be discussing about the hardware optimization for Moodle. In this session, I would like to discuss about one or two experiments which we did so as to optimize Moodle at the back end. That is, so as to reduce the database latency. Actually, we performed a lot of experiments on this. But in our experiments, we focused mainly on testing a Moodle on a system loaded with a solid state disk against a system loaded with a hard disk drive. Actually, before moving on to the experiment, I would like to discuss some features of the SSD. Like, as a first step to hardware optimization, what we did was we just did a quick review of these features. And this gave a reason. Okay, sorry. Then I'll skip the features. This is my experiment. I did, my objective of my experiment was database optimization, how, what the difference is by loading the database in an SSD. So these are the quiz details. The experiment was done on the quiz module in Moodle. We used a dummy Moodle for that with two users. And the user was made to give a quiz. The quiz contained five questions. And five questions were a mixture of all the types, like MCQ, true of all, etc. And the quiz was given in a random way, totally random, so that it included both right and wrong answers, so that we get a mixture of queries. And all the queries that were generated were logged and which was obtained. And this table gives the number of queries that were generated. And this was obtained by flushing the query log from time to time. And Moodle actually generates a lot, lot of queries for each activity. And we are interested in the quiz which is, okay. The reason is that the queries which Moodle fires are like, it fires unwanted queries too. Like if instead of fetching two or three columns, it fetches the whole table as such. It, it never uses select some columns. It always uses select star from each table. And yeah, the Moodle, the database queries which I fired are not optimized queries. So the quiz contained 554 queries. Now, coming on to the experiment, the test was done on four different systems. I tested it on IPRI, IPIN, i7 and systems and also on systems loaded with SSD and HDD. So this provided me a varying configuration of RAM and CPU. So coming down to the results, as you can see, the right most end gives the result of the SSD. And while compared to all of our systems, a system loaded with a hard disk drive takes at least 2.5 seconds, at least 2.5 seconds as compared to an SSD. So we plotted a graph, this was done for a single user and we plotted a graph and a factor was calculated. So the average time for a single user has given there. We averaged it out and the factor was around 3.65. So in order to confirm my results, I just did it for 100 users and the time were times in seconds, it is a time in seconds. We obtained these times, the factor was again 3.68, it was 3.65 before. So coming to the last part, whatever the number of users we get, when a hard disk is used, there is a latency delay of three times as compared to a solid-state drive. So another feature, we are using MySQL database for Moodle. MySQL database supports more number of simultaneous logins if more RAM is used. So using an SSD server with maximum possible RAM, with maximum possible RAM, can boost up the performance of Moodle database. It can reduce latency of the database. That was my experiment. I am only focusing on the communication mechanism code of the Moodle and it was experimentation proposed for this where implementation of long polling and random batch mode algorithm. Long polling is keeping a pending request of client over the server side until a updated response can be returned to the client. The benefits, there are number of benefits of long polling. A smaller number of requests from the server side to the server side from the client are sent and this reduces the traffic bandwidth usage is reduced. Repeated request method which earlier used was short polling. In that method repeated request. So the repeated request establishment time was in highly more. So this reduced the establishment time of the request and response. Now long polling benefits are after long polling. How this technique works? This technique works that whenever request is sent to server the response is only sent when the database has a new data to send. The database queries are very frequent. So there is no much time lag in that but when a updated data is received the response is set at that time and the next request is displayed after the new response. This reduces traffic. Implementation to Moodle. This quiz was implemented to Moodle in such a way that the time request code from the plugin was removed and after that a variable was set so that it will indicate in which mode. It is in quiz mode, send question mode, so result mode and this status was used to hand over the response to the client side. Results of this were that every question there was a reduction of request by factor of 3. Every question the request was reduced by factor of 3. But when I tested with Jmeter both the quiz short polling and long polling they worked for 90 user. But throughput was better for long polling. But after this 90 user they both crashed because of RAM limitation. Now the second proposal algorithm was a random batch mode algorithm. It was already tested for Akash but this time we are using implementing this algorithm for Moodle. So that Moodle quiz will be implemented over Akash and it has many features that could be utilized. Under this algorithm users are good by the random numbers generated by the algorithm. Results are that over my system which is I3-Posizer 3GB RAM and Ubuntu 10.04. For 60 users both worked fine for 75 users. The random number generation work but the previous was limitation of 60. At that time only it was hard to conduct the quiz. So for 75 it crashed completely but for 75 users the random number generation work fine. So these are the results. It works fine. So we also made an interface for policy framework and now we'll go to future scope. Now we have made an interface for policy framework but if we integrate this policy framework with Moodle we can use the policy enforcement framework for Moodle activities like quiz, chat and various other activities. And another optimization is database optimization. We can minimize the most expensive queries which are fired by the database. And the next is that if we share the load of Moodle on different servers this is also another optimization technique. So we learned a lot of things from this project. Like we learned JMeter, Apache JMeter we learned about various optimization techniques. We got an in-depth understanding of web and web server and client communication. These are some of the apps that we developed. So I'd like to thank Mr. Fatah for giving us this valuable opportunity. This has been a really memorable event of our lives. Thank you once again. Thank you. Thank you very much. I do not know whether all of you appreciate the importance of this particular project in practical terms. IIT Bombay has been using Moodle for years. And even within IIT we have a problem when a large number of students latch on to give one particular quiz or a feedback form the Moodle response to all other users reduces. There are about 8,000 students and 550 faculty members who use Moodle regularly. Fortunately the usage is distributed in time and therefore it does not affect us. But when we tried to use this for our 10,000 teachers training program, we used it for our 1,000 teachers training program and we could easily conduct a distributed quiz or an assignment for a feedback form for 1,000 teachers from about 50 remote centers. But when we scaled up to 10,000 teachers the Moodle used to regularly crash at about 2,000 teachers. Now I do not get a sense of how do I correlate these 65, 70 users or 30, 50, 60 users that you have reported with 2,000 users who are routinely able to do the feedback. So most rarely you have not included appropriate think time. Sir actually depends on the run. The IITB is using a separate database for website loading and separate database for database. So you did not do the server for database. It is of 96 GB RAM. Is there a sysad present here? Mayank, can you carry this feedback to our sysad team? Abilash is busy getting married but he will be back soon. You tell them that they should do the same JMeter testing with these optimizations on the main server. So before we run the next 10,000 teachers course in December I think we should be able to solve this problem. No, that's right. So yeah, so you are firing transactions as soon as one is over. That is not what happens in real life. You can crash any system including a supercomputer. Anyway, but excellent work done. I hope you have learned a lot in the process. Thank you so much.