Part 1: Confirm performance factors for Discussion API

MA-1099 - Getting issue details... STATUS

Endpoints: 

• /courses/(course_id)/
  • GET
• /course_topics/(course_id)
  • GET
• /threads/
  • GET
  • POST
• /threads/(thread_id)
  
  • GET
  • PATCH
  • DELETE 
•  /comments
  • GET 
  • POST
•  /comments/(comment_id)
  • GET not implemented
  • PATCH 
  • DELETE
    

Notes and considerations:

Thread and Comment pool:

    Various methods of select post data were considered.

• Selecting threads from a smaller pool or selecting the same thread.  Rather than getting the entire list of thread_ids to send requests against, we would just store a random portion of the threads. A test was run to see if matters whether the retrieved thread was random or not, but the sandbox it was run against did not have the correct mongo indexes set up. Regardless, this strategy would not work when trying to DELETE threads as the pool of potential threads would be smaller. Additionally this relies on storing data that must be shared amongst the locust users which could lead to race conditions as a locust user could be trying to GET a thread that another locust user was in the middle of DELETEing. When dealing with much larger file IO operations, it could cause some limitations on the machine that spawns the locusts.
• Retrieving the list of thread ids when starting locust. This method was effective up until the number of threads in the data set started to increase. As the median number of posts in a course is ~2000, when trying to retrieve 20*(page size max of 100), it would take 20 queries. Additionally, as mentioned in the above strategy, storing data amongst the locust users is not a trivial task. Each locust user would try to generate it's own list of threads which is unacceptable. If a thread was POSTed or DELETEd, only that locust user would have that updated information. Attempts at using the lazy module did not work either as each list of threads was instantiated separately by each locust user. Again, even if the locust users were able to use the same global variables, there would be race conditions. 
• Calling GET thread_list per DELETE/PATCH/GET_comment. Since the ratio of GET thread_list is significantly higher than any of the other calls, we can achieve the desired distribution of requests for the discussion API. 

• Action	Count
  .forum.views:single_thread	675980	4760
  .forum.views:forum_form_discussion	234783	1653
  .forum.views:inline_discussion	155176	1093
  create_thread	31176	220
  create_comment	27438	193
  create_sub_comment	14345	101
  users	13820	97
  .forum.views:user_profile	12336	87
  .forum.views:followed_threads	7698	54
  vote_for_comment	6731	47
  vote_for_thread	6242	44
  upload	4208	30
  update_comment	3403	24
  follow_thread	3870	27
  update_thread	2827	20
  delete_thread	2091	15
  endorse_comment	1232	9
  delete_comment	770	5
  flag_abuse_for_comment	373	3
  flag_abuse_for_thread	142	1

• Using pre-stored thread_id data. 

Things that were left out:

• Pin Thread - Not implemented
• Open/Close Thread -Not implemented

 Staff vs. Normal User:

    Using users with staff access was thrown into consideration as it would be make some of the permissions a bit more difficult for some discussion forums actions such as editing the body of a thread. Some tests were ran to see if there was a difference. No difference was found the tests that were designed to check for a difference. 

/threads/

GET: 

POST: 

/threads/{thread_id}

GET: 

Waiting on Loadtest env to get meaningful results. Refer to /threads/get

PATCH: 

DELETE:

/comments/

GET: 

POST: 

POST should be similar to POSTing threads. 

/comments/comment_id

PATCH: 

DELETE: 

DELETE is best tested with the other endpoints. For every comment delete, we POST a thread, GET a random thread, and then DELETE that random thread.