I have a couple of questions that have been bothering me for quite some time now, but I lack the expertise (and time) to find an understandable answer. I am not looking for a very detailed answer here. I just would like to understand how Ecto deals with stress in broad terms.
I have to deal with say 500 people who will use my Phoenix app concurrently in an experiment. I have written a similar application in Rails and it all went horribly wrong. I am happy to share the details if you want. I suspect that it went wrong because the state of a database table didn’t get updated fast enough. The problem could not be simulated with ‘simple’ tests, it only occurred during a high load.
So here’s what bothering me: the said 500 folks start hitting the database like they want to destroy it. I have a connection pool of 25 connections. Imagine the Phoenix app has to deal with 500 queries in a very short timeframe. The first 25 of these 500 get a connection and are being processed. A number of these 25 are update queries on several records in the users table. Now imagine one other fast query has been processed and now there is room for query 26 which is a select query on the users table. But not all update queries are finished.
- Do I understand correctly that a single queue is used in Ecto to deal with the 500 incoming queries?
- Would query 26 get a ‘wrong’ state of the database (it came in as query 26, assuming all update queries were done, but they are still being processed).
- Is there anything smart that I missing here in terms of procedure. Maybe query 26 is put on hold because other queries that deal with the same table are still processed…)
Let me know if you need more info, or if I didn’t described it well enough.
Thanks in advance.