gevent和twisted对比

Twisted

在事件驱动版本的程序中,3个任务交错执行,但仍然在一个单独的线程控制中。当处理I/O或者其他昂贵的操作时,注册一个回调到事件循环中,然后当I/O操作完成时继续执行。回调描述了该如何处理某个事件。事件循环轮询所有的事件,当事件到来时将它们分配给等待处理事件的回调函数。这种方式让程序尽可能的得以执行而不需要用到额外的线程。事件驱动型程序比多线程程序更容易推断出行为,因为程序员不需要关心线程安全问题。

Gevent

当前协程繁忙时,主动的放弃CPU资源,等到以后再运行。

协程和事件驱动:

最近在研究网络服务框架方面的东西,发现了一个神奇的东西-协程。 
一句话说明什么是线程:协程是一种用户态的轻量级线程。 
从硬件发展来看,从最初的单核单CPU,到单核多CPU,多核多CPU,似乎已经到了极限了,但是单核CPU性能却还在不断提升。server端也在不断的发展变化。如果将程序分为IO密集型应用和CPU密集型应用,二者的server的发展如下: 
IO密集型应用: 多进程->多线程->事件驱动->协程 
CPU密集型应用:多进程–>多线程 
如果说多进程对于多CPU,多线程对应多核CPU,那么事件驱动和协程则是在充分挖掘不断提高性能的单核CPU的潜力

同步和异步的比较

无论是线程还是进程,使用的都是同步进制,当发生阻塞时,性能会大幅度降低,无法充分利用CPU潜力,浪费硬件投资,更重要造成软件模块的铁板化,紧耦合,无法切割,不利于日后扩展和变化。不管是进程还是线程,每次阻塞、切换都需要陷入系统调用(system call),先让CPU跑操作系统的调度程序,然后再由调度程序决定该跑哪一个进程(线程)。多个线程之间在一些访问互斥的代码时还需要加上锁,这也是导致多线程编程难的原因之一。 
现下流行的异步server都是基于事件驱动的(如nginx)。事件驱动简化了编程模型,很好地解决了多线程难于编程,难于调试的问题异步事件驱动模型中,把会导致阻塞的操作转化为一个异步操作,主线程负责发起这个异步操作,并处理这个异步操作的结果。由于所有阻塞的操作都转化为异步操作,理论上主线程的大部分时间都是在处理实际的计算任务,少了多线程的调度时间,所以这种模型的性能通常会比较好。 
总的说来,当单核cpu性能提升,cpu不在成为性能瓶颈时,采用异步server能够简化编程模型,也能提高IO密集型应用的性能。

协程和线程

之前说道,协程是一种用户级的轻量级线程。协程拥有自己的寄存器上下文和栈。协程调度切换时,将寄存器上下文和栈保存到其他地方,在切回来的时候,恢复先前保存的寄存器上下文和栈。因此: 
协程能保留上一次调用时的状态(即所有局部状态的一个特定组合),每次过程重入时,就相当于进入上一次调用的状态,换种说法:进入上一次离开时所处逻辑流的位置。 
在并发编程中,协程与线程类似,每个协程表示一个执行单元,有自己的本地数据,与其它协程共享全局数据和其它资源。等待线程会抢占cpu,而协程会主动放弃cpu。不管是进程还是线程,每次阻塞、切换都需要陷入系统调用(system call),先让CPU跑操作系统的调度程序,然后再由调度程序决定该跑哪一个进程(线程)。 
而且由于抢占式调度执行顺序无法确定的特点,使用线程时需要非常小心地处理同步问题,而协程完全不存在这个问题(事件驱动和异步程序也有同样的优点)。

协程和事件驱动

以nginx为代表的事件驱动的异步server正在横扫天下,那么事件驱动模型会是server端模型的终点吗? 
事件驱动编程的架构是预先设计一个事件循环,这个事件循环程序不断地检查目前要处理的信息,根据要处理的信息运行一个触发函数。其中这个外部信息可能来自一个目录夹中的文件,可能来自键盘或鼠标的动作,或者是一个时间事件。这个触发函数,可以是系统默认的也可以是用户注册的回调函数。 
事件驱动程序设计着重于弹性以及异步化上面。许多GUI框架(如windows的MFC,Android的GUI框架),Zookeeper的Watcher等都使用了事件驱动机制。未来还会有其他的基于事件驱动的作品出现。 
基于事件驱动的编程是单线程思维,其特点是异步+回调。 
协程也是单线程,但是它能让原来要使用异步+回调方式写的非人类代码,可以用看似同步的方式写出来。它是实现推拉互动的所谓非抢占式协作的关键。

总结:

协程的好处:

跨平台
跨体系架构
无需线程上下文切换的开销
无需原子操作锁定及同步的开销
方便切换控制流,简化编程模型
高并发+高扩展性+低成本:一个CPU支持上万的协程都不是问题。所以很适合用于高并发处理。

缺点:

无法利用多核资源:协程的本质是个单线程,它不能同时将 单个CPU 的多个核用上,协程需要和进程配合才能运行在多CPU上.当然我们日常所编写的绝大部分应用都没有这个必要,除非是cpu密集型应用。
进行阻塞(Blocking)操作(如IO时)会阻塞掉整个程序:这一点和事件驱动一样,可以使用异步IO操作来解决

转载于:https://my.oschina.net/u/3346994/blog/903420

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 这取决于您的应用程序的特定用例和配置。 gevent 是一个基于协程的 Python 并发库,它使用协程来支持高并发网络应用程序。它通过轮询底层操作系统的 I/O 事件,并在可用时自动切换任务来实现高并发。 gunicorn 是一个高性能 WSGI 服务器,用于运行 Python web 应用程序。它使用一种叫做“工作进程”的机制来支持多个请求同时处理。 在一般情况下,gunicorn 的性能要优于 gevent。然而,这取决于您的应用程序的特定用例和配置。例如,如果您的应用程序使用了大量的 CPU 密集型任务,则 gevent 可能优于 gunicorn,因为它可以在执行这些任务时自动切换协程。 总的来说,两者都是可以用来开发高性能网络应用程序的工具,但是哪个性能更高取决于您的应用程序的特定用例和配置。建议您进行性能测试,以找出哪个工具在您的应用程序中表现最佳。 ### 回答2: gevent和gunicore是用于Python网络应用程序开发的两个不同的工具。虽然它们具有不同的功能和用途,但无法简单地确定哪个的性能更高,因为它们是为不同需求和使用场景设计的。 gevent是一个基于协程的网络库,它提供了异步IO和并发编程的支持。它使用了协程和事件循环机制来实现高性能的网络编程。在适当的情况下,使用gevent可以提高应用程序的性能,特别是在需要处理大量并发连接的情况下。然而,gevent主要适用于IO密集型的应用程序,对于CPU密集型的任务可能效果并不好。 gunicorn(Green Unicorn)是一个用于运行Python WSGI服务器的工具。它使用了pre-fork worker进程模型,可以处理多个并发请求。gunicorn可以与gevent结合使用,以提高应用程序的性能。使用gunicorn的主要优点是它的稳定性和可靠性,它经过了长时间的发展和测试,并且支持在生产环境中进行部署。 综上所述,无法简单地说哪个工具的性能更高,因为它们是为不同的需求和使用场景设计的。如果您的应用程序是IO密集型的,并且需要处理大量并发连接,可以考虑使用gevent。如果您的应用程序是使用WSGI架构的,并且需要提供稳定和可靠的性能,可以考虑使用gunicorn。最佳的选择将取决于您的具体需求和应用程序的特点。 ### 回答3: 首先,需要明确的是,gevent和gunicorn是两个不同的工具,用于不同的情境。gevent是一个基于greenlet协程的Python网络库,旨在提供高性能的并发编程解决方案;而gunicorn是一个用于运行Python Web应用程序的HTTP服务器。 就性能而言,在处理高并发情况下,gevent通常比gunicorn更高效。它利用了绿色线程和事件循环机制,能够在单个线程内同时处理大量并发请求,提供了更好的资源利用率,并减少了线程切换的开销。相比之下,gunicorn使用多进程模型,每个进程可以独立处理请求,但对于每个进程来说,需要独占一定的系统资源,这可能导致总体资源的浪费。 然而,这并不意味着gevent在所有情况下都比gunicorn更高效。如果你的应用程序主要是计算密集型任务,而不是I/O密集型(如网络请求),那么gunicorn在处理请求时可能更合适。因为gevent的协程机制并不能在计算密集型任务中提供多线程的性能优势。 综上所述,对于大多数情况下的高并发I/O密集型应用程序,gevent在处理性能上可能更优。但在其他情况下,gunicorn可能更适合。在选择时,请根据你的具体需求和应用程序类型进行评估。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值