Previous we had around 4 copies of the logic for deciding whether we
should publish data via a SimpleQueueClient queue, a
TornadoQueueClient queue, or to directly handle the operation, which
resulted in their getting out of sync and buggy (see e.g. the previous
commit).
We need to add a lock around adding things to the queue to work around
a bug with pika's BlockingConnection.
I should note that the previous logic in some places had a bunch of
tests of the form "elif settings.TEST_SUITE" for doing the work that
would have been done by the queue processor directly; these should
have just been "else" clauses -- since we generally want that code to
run on development environments whether or not the test suite is
currently running.
(imported from commit 16bdbed4fff04b1bda6fde3b16bee7359917720b)
Previously we had several files which initialized SimpleQueueClient()
for sending items to the UserActivity queue, even though those code
paths aren't used outside Tornado. This resulted in slower Tornado
startup times.
(imported from commit ad97021ec18d3927233744037c548c22db33c321)
The actual database query that we use to fill the UserMessage cache
only takes a few hundred milliseconds to run; however the process of
iterating through the results would take 3-5 seconds because the
Django ORM is not very efficient for small tables where we're only
interested in the integer values in a couple columns.
So we can save most of that Tornado startup time by just doing this
one query manually; I left the original query next to it in a comment
so it is easy to keep it all up to date as we change our product.
(imported from commit ac4675bcdda5d812ebfbe211450c85ee2787ee66)
Tim Abbott
Leo Franchi
Keegan McAllister