So I’ve been trying to understand why sometimes our data validation interface times out (i.e. takes >60s) when it should only take 3 seconds.
My first hunch was that it had to do with wsgi and numpy globals, but it turns out we’re not running mod_wsgi.
My second hunch is that maybe it has to do with atomic transactions that may be happening in longer processes elsewhere in the background. I may be able to reproduce this with some testing now that I have this hunch, but I’m posting here to try and learn a bit more about how atomic transactions affect concurrent database operations.
From what I understand from reading today on this topic, concurrent database operations happening in atomic transaction blocks can work OK unless they’re working on the same records. One question I have is: what if both processes are only doing inserts (via get_or_create()), but on the same database tables? If all our models use a primary key that’s an “autofield”, can there be contention WRT to “next” ID? If they’re both trying to insert into the same table, does the second one end up waiting or do they each get a new sequential ID and continue on?
Added context: The timeouts I’ve rarely/randonly encountered happened during concurrent “dry runs”. Both sets of atomic transactions were destined to be rolled back at the end. Is there a way to take advantage of that? For example, could I tell the atomic transaction ahead of time that it doesn’t need to wait on what happens in any concurrent transactions and proceed (because I plan to roll back anyway)?
Incidentally, this is partly a side-effect of some sub-optimal pandas code that runs pretty slow. We have plans to refine that code, but it’s also because some datasets being operated on are just huge too. Also (side note), we might explore some bulk-create operations where possible. We don’t use any currently, and our reliance on some clean method operations might prohibit usage of bulk create.