gunicorn and sqlalchemy mtulti螺纹/多个工人似乎是不平行的
我正在使用SQLalchemy连接到数据库的连接。我正在经营9名工人，每个工人都应该拥有自己的数据库引擎（因为每个枪支工人都运行烧瓶API脚本的副本）。虽然这些确实是在独立工人中运行的（我有在呼叫之前出现的打印语句，这向我指示有多个工人同时处理呼叫）。
假设呼叫A，B，C和D的情况大多都是相同的，并且微小的差异。 当我打电话时 - 呼叫A - 需要x时间。 当我连接两个呼叫时 - 呼叫A和B-需要X +的时间。 当我连接三个呼叫时 - 呼叫A和B和C-这需要X ++的时间。
我不明白为什么会这样。每个工人都有自己的连接，每个引擎仅运行读取请求。
app.route("/A")
def A():
stmt = select([x,y,z])
res = engine.execute(stmt)
app.route("/B")
def B():
stmt = select([x,x,z])
res = engine.execute(stmt)
app.route("/C")
def C():
stmt = select([x,y,x])
res = engine.execute(stmt)
app.route("/D")
def D():
stmt = select([z,y,z])
res = engine.execute(stmt)
我不明白为什么一个运行呼叫的工人会减慢运行呼叫的另一个工人（在数据库侧发生放缓以返回数据）。
I am running a flask application with a connection to a database using sqlalchemy. I am running 9 workers and each of the workers should have their own database engine (since each gunicorn worker runs a copy of the flask api script). While it does appear that these are running in independent workers (I have print statements that appear before the call is over which indicate to me that there are multiple workers working on calls concurrently).
Lets say calls A, B, C and D are all mostly the same with slight dissimilarities.
When I run a single call -- call A -- it takes x amount of time.
When I run two calls -- call A and B -- it takes x + amount of time.
When I run three calls -- call A and B and C -- it takes x ++ amount of time.
I do not understand why this would be the case. Each worker is getting its own connection, and each engine is only running read requests.
app.route("/A")
def A():
stmt = select([x,y,z])
res = engine.execute(stmt)
app.route("/B")
def B():
stmt = select([x,x,z])
res = engine.execute(stmt)
app.route("/C")
def C():
stmt = select([x,y,x])
res = engine.execute(stmt)
app.route("/D")
def D():
stmt = select([z,y,z])
res = engine.execute(stmt)
I don't understand why one worker running a call would slow down another worker running a call (where the slowdown is occurring is on the database side to return the data).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过大量挖掘，事实证明请求是并发的。但是，拆卸和设置以及数据库必须做的工作以确保所有呼叫共享相同的信息以便从一部写入的情况下导致更长的时间，在这种情况下，多个调用相互影响。并行化没有问题，我认为问题是2 GB，并且数据库努力扫描表并在短时间内分配资源
After a lot of digging, turns out that the requests are concurrent. However, the teardown and set up as well as the work the database has to do to ensure that all the calls share the same information to pull from in case one does a write are leading to longer times in which multiple calls affect each other. There is no problem with parallelization, the issue lies in my view being 2 GB big and the database struggling to scan the tables and allocate resources in a short period of time