NathanRSmith
commented
12 years ago An alternative for the app as a whole would be to find a way to create a new resource with all the other resources as child resources. Then just issue one request per refresh cycle that requests the parent resource, which gathers all the data from the child resources that would normally be requested individually and returns one big json dict.
http://django-tastypie.readthedocs.org/en/latest/cookbook.html#nested-resources may be helpful.
I'm not sure how much this would improve efficiency, but as I've been developing, I've noticed that the cpu usage increases considerably with the number of annotations in a room. I have the bigboard running in a Centos 6 VM with apache/mod_wsgi running in virtualbox with 2 cores available at 100% cap on my macbook pro. I'm using postgis for the db.
When I first started working with a room I had very few annotations, maybe 10 or less which would take about 30% cpu for a second each time the mainloop was run with django debug on. Now I have 58 annotations being returned with every api request. The content size returned is ~78KB and takes ~1.4s to return for me in these circumstances. Now it regularly runs at 130% with just one instance open for a couple seconds until the next round starts again.
On the server, load drops dramatically with django debug turned off from ~120% to ~12% every few secs.
I know that django debug is responsible for a lot of the load in my development case, but I wonder if it might be worth it to improve the loop efficiency since 12% can quickly add up when you have users doing real things, especially if they have multiple rooms open at the same time.
For annotations I think we could adopt a method like you've done with chat where only the annotations since the last request are retrieved and sent. This obviously causes issues with telling if an annotation has been deleted, but I think we could come up with some scheme where bool and timestamp fields are added to the annotations model that tells whether the annotation has been deleted and when it should expire (probably a few minutes after it is marked deleted to make sure open rooms have a chance to get the delete notice). Then the select statement would be modified to retrieve all since last request or any that are marked deleted and have the js callbacks check the flag. There would be a periodic celery task to clean up deleted annotations that have expired, after which point they would no longer be returned.