Maybe it's slow because all database access goes through the single queue (Or maybe there's just too many deferred's scheduled)

Too tired to test the hypothesis this evening, but I'm wondering if the reason the user interactions are being held up so long is that they are trying to execute a database operation. Database operations are linearised to avoid deadlocks, which could quite readily be resulting in any given database-dependent operation taking a long time to clear (if the database queue is long).

Solving it should be as simple as adding a "high priority" flag to the database operations and having them inserted at the front of the queue instead of the end... may be some concurrency issues there, but shouldn't be too bad given the nature of the vast majority of updates in the system.


Comments are closed.


Pingbacks are closed.