Database performance modifications

[charlesbaynham]

• Go back to lazy queries, but add eager relationships to models where needed
• Bake get_game query to save 400ms! (Must do for other queries / avoid other queries)
• Add debugging options as environmental variables

Closes #133

[charlesbaynham]

These are the updates as a result of #139.

[charlesbaynham]

Testing performance improvements

Method

1. Get the DATABASE_URL from the heroku dyno running for this (or any) PR so that I'm testing against a real postgres database on a remote server. E.g. heroku run --app wurwolves-lazy-and-bake-7lwfq1 echo \$DATABASE_URL
2. Add this to the .env local file
3. Set IGNORE_TESTING_DB=true in .env
4. Run pytest -k state_speed
5. Check final report on state rendering speed.

Results

In master branch (1bfcc0f89d24a0f314da2cb4fd04f6e292ae80c2) render time is

WARNING  root:test_backend.py:85 time_per_join = 0.358s of which 0.302s in 12.4 DB calls
WARNING  root:test_backend.py:90 time_per_render = 0.100s of which 0.058s in 1.0 DB calls

In this branch (at 73ca49337dce3546d8e318e85e3692a09898d5a4) render time is

WARNING  root:test_backend.py:85 time_per_join = 0.751s of which 0.663s in 15.4 DB calls
WARNING  root:test_backend.py:90 time_per_render = 0.385s of which 0.337s in 13.0 DB calls

Errrrrmmmm I thought I'd made it better.

[charlesbaynham]

Test method 2

1. Make 10x Selenium clients and point them to https://wurwolves.com/test_game or the equivalent on this PR.
2. Find a wolf
3. Turn on network analytics
4. Choose someone to wolf and check the time taken to get the state

This method is more representative of a real game: the code on master is fast when the games are trivially small, but slows down as they grow large.

Results

On master (i.e. wurwolves.com, at 1bfcc0f89d24a0f314da2cb4fd04f6e292ae80c2):

Either 3900 or 12400 ms.

On this branch (i.e. https://wurwolves-lazy-and-bake-7lwfq1.herokuapp.com/ at 73ca49337dce3546d8e318e85e3692a09898d5a4):

422ms.

[charlesbaynham]

Repeating above, but altering the test protocol by adding "start game, abort game, start game, abort game, start game" to simulate a long-running session.

This PR

135ms

master

Could not do the test. Starting the third game took so long and consumed so much memory that the app exceeded its limits and crashed.