peewee和peewee-异步:为什么异步比较慢？

Question

我正试图将我的头脑集中在与Postgresql的旋风和异步连接上。我在http://peewee-async.readthedocs.io/en/latest/找到了一个可以这样做的库。

我设计了一个小测试来比较传统的Peewee和Peewee-异步，但是异步的工作速度要慢一些。

这是我的应用程序：

import peewee
import tornado.web
import logging
import asyncio
import peewee_async
import tornado.gen
import tornado.httpclient
from tornado.platform.asyncio import AsyncIOMainLoop

AsyncIOMainLoop().install()
app = tornado.web.Application(debug=True)
app.listen(port=8888)

# ===========
# Defining Async model
async_db = peewee_async.PooledPostgresqlDatabase(
    'reminderbot',
    user='reminderbot',
    password='reminderbot',
    host='localhost'
)
app.objects = peewee_async.Manager(async_db)
class AsyncHuman(peewee.Model):
    first_name = peewee.CharField()
    messenger_id = peewee.CharField()
    class Meta:
        database = async_db
        db_table = 'chats_human'


# ==========
# Defining Sync model
sync_db = peewee.PostgresqlDatabase(
    'reminderbot',
    user='reminderbot',
    password='reminderbot',
    host='localhost'
)
class SyncHuman(peewee.Model):
    first_name = peewee.CharField()
    messenger_id = peewee.CharField()
    class Meta:
        database = sync_db
        db_table = 'chats_human'

# defining two handlers - async and sync
class AsyncHandler(tornado.web.RequestHandler):

    async def get(self):
        """
        An asynchronous way to create an object and return its ID
        """
        obj = await self.application.objects.create(
            AsyncHuman, messenger_id='12345')
        self.write(
            {'id': obj.id,
             'messenger_id': obj.messenger_id}
        )


class SyncHandler(tornado.web.RequestHandler):

    def get(self):
        """
        An traditional synchronous way
        """
        obj = SyncHuman.create(messenger_id='12345')
        self.write({
            'id': obj.id,
            'messenger_id': obj.messenger_id
        })


app.add_handlers('', [
    (r"/receive_async", AsyncHandler),
    (r"/receive_sync", SyncHandler),
])

# Run loop
loop = asyncio.get_event_loop()
try:
    loop.run_forever()
except KeyboardInterrupt:
    print(" server stopped")

这就是我从Apache Benchmark那里得到的：

ab -n 100 -c 100 http://127.0.0.1:8888/receive_async

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.5      5       7
Processing:   621 1049 256.6   1054    1486
Waiting:      621 1048 256.6   1053    1485
Total:        628 1053 255.3   1058    1492

Percentage of the requests served within a certain time (ms)
  50%   1058
  66%   1196
  75%   1274
  80%   1324
  90%   1409
  95%   1452
  98%   1485
  99%   1492
 100%   1492 (longest request)




ab -n 100 -c 100 http://127.0.0.1:8888/receive_sync
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    5   1.9      5       8
Processing:     8  476 277.7    479    1052
Waiting:        7  476 277.7    478    1052
Total:         15  481 276.2    483    1060

Percentage of the requests served within a certain time (ms)
  50%    483
  66%    629
  75%    714
  80%    759
  90%    853
  95%    899
  98%   1051
  99%   1060
 100%   1060 (longest request)

为什么同步更快？我错过的瓶颈在哪里？

Answer 1

为了得到很长的解释：

http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/

简单地解释一下:同步Python代码很简单，并且主要是在标准库的套接字模块(纯C )中实现的。异步Python代码比同步代码更复杂。每个请求都需要几个主事件循环代码的执行，这些代码是用Python编写的(在这里的asyncio中)，因此与C代码相比有很多开销。

像您这样的基准测试显示了异步的巨大开销，因为您的应用程序和数据库之间没有网络延迟，而且您正在执行大量非常小的数据库操作。由于基准测试的每一个其他方面都是快速的，所以事件循环逻辑的这许多执行增加了整个运行时的很大一部分。

上面链接到的Mike的论点是，像这样的低延迟场景对于数据库应用程序来说是典型的，因此不应该在事件循环上运行数据库操作。

异步最适合于诸如websockets和web爬虫这样的高延迟场景，在这些场景中，应用程序将大部分时间用于等待对等程序，而不是将大部分时间用于执行Python。

总之:如果您的应用程序有充分的理由使用异步(它处理的是慢的对等程序)，那么为了代码的一致性，使用异步数据库驱动程序是个好主意，但需要一些开销。

如果您出于另一个原因不需要异步，就不要执行异步数据库调用，因为它们的速度有点慢。

Answer 2

数据库对象为异步体系结构引入了许多复杂性。在ORM中有几个地方可能会发生阻塞，并且可以改变为异步形式。阻塞发生的地方也可能因数据库而异。我猜测您的结果为何如此缓慢，是因为事件循环中有许多未优化的调用(我可能大错特错，最近我主要使用SQLAlchemy或原始SQL )。根据我的经验，在线程中执行数据库代码并在可用时生成结果通常更快。我不能真正代表PeeWee，但是SQLAlchemy非常适合在多个线程中运行，也没有太多的缺点(但是那些确实存在的方面非常恼人)。

我建议您尝试使用ThreadPoolExecutor和同步Peewee模块进行实验，并在线程中运行数据库函数。您将不得不对您的主要代码进行更改，但是如果您问我，这将是值得的。例如，假设您选择使用回调代码，那么ORM查询可能如下所示：

from concurrent.futures import ThreadPoolExecutor

executor = ThreadPoolExecutor(max_workers=10)

def queryByName(name):
    query = executor.submit(db_model.findOne, name=name)
    query.add_done_callback(processResult)

def processResult(query):
    orm_obj = query.results()
    # do stuff with the results

您可以在协同器中使用yeild from或await，但这对我来说有点问题。而且，我还不太熟悉合作。只要devs小心死锁、db会话和事务，这段代码段就应该可以很好地处理“旋风”。如果线程中有问题，这些因素确实会减缓应用程序的速度。

如果您感到非常冒险，MagicStack (异步的公司)有一个名为asyncpg的项目，它应该非常快！我一直想试一试，但没有找到时间