Skip to content

Performance

brandon edited this page Apr 14, 2017 · 4 revisions

Performance

Issues Identified

There were 3 issues identified related to performance throughout the project.

  • Searching was slow and sluggish because modules were searched with regex inside the database
  • Graduation checker has a perceivable lag time due to slow calculation
    • Using Safari's web inspector with the Timelines tab to record the time taken for the graduation checker to run , it takes about 2 seconds for the script to complete running.
    • This happens when the user first switches to the graduation requirement tab or if they are already on the tab and added / removed a new module into their planner
  • Based on Google’s PageSpeed benchmark, we received a score of 81/100. This is mainly due to javascript block other resources from loading.

Implemented solutions

  • Searching was improved by pre-loading all 7000 modules from a json file inside our public repository. By doing this, search-controller does a search from a local variable rather than doing a find() inside the database. This improved performance by at least 2 seconds per module search

Future performance improvements

  • Possible solutions to solve the slow graduation checking
    • Reduce the number of loops that is need to run graduation checker. Worse case with current algorithm happens in focus area where it runs 3 nested for loops to check if student has cleared 24 MCs of modules
    • Each module search to check required MCs does a search in the database to retrieve a single module's MC. Future implementations can make use of the JSON file inside the public folder by storing the information inside a Javascript object and passing it to the graduation checker for quicker access. This is similar to how the current module searching works except the cached modules must be in an object format rather than an array format

Load testing report

Blazemeter was used as the server to run the threads for load testing

  • At 50 users/second accessing the main page of NUS-oracle
    • JMeter configuration:
      • HTTP request type: GET
      • Retrieves all HTML embedded resources

Blazemeter report:

Title Value
Average response time 7.75s
Average throughput 6.48 hits/s
Errors 0

Heroku report:

Title Value
Median response time 203 ms
Max RSS 208MB / 512 MB
Average memory used 159.4 MB

Based on the heroku report for memory usage, there does not seem to be an increasing trend of memory usage on the server side. Therefore, it can be safe to assume that loading the front page does not cause memory leaks