阿帕奇+ mod_wsgi +持久的Python应用程序 - 我想我错过了一块

发布于 2025-01-08 11:56:52 字数 682 浏览 0 评论 0原文

Ubuntu 11.10、Python 2.6。背景:我有一个现有的 Python 应用程序,它使用 Twisted 循环等待 RESTful 命令进入。因此应用程序启动,启动执行各种操作的线程,并且 main 为 Twisted 设置回调,然后调用Twisted.reactor.run(),永远阻塞。当请求到来时,适当的处理程序被调用,事情发生,回复被发回。

我现在的工作是删除 Twisted,因为管理层认为他们不喜欢它。我们正在转向 Apache 作为我们的 Web 服务器。

使用文档,我已经成功安装并配置了 Apache2.0 来提供网页服务。我还安装了 mod_wsgi,并且能够配置它和 Apache 在收到请求时执行任意 Python 代码。所以我在这方面很擅长。

我缺少的是如何将我的 Python 应用程序连接到 Apache/mod_wsgi 位,因为应用程序需要持久且始终运行。有人建议我在 wsgi 脚本和主应用程序之间打开一个管道,并以这种方式序列化请求。但似乎这应该已经存在了,我只是不知道要搜索什么。

任何朝正确方向的推动都将受到高度赞赏。

为了清楚起见,进一步编辑:我不是在制作网络服务器。相关应用程序是在虚拟机上运行的主机应用程序。它恰好由 RESTful 接口通过 HTTP 进行控制。因此它需要做的就是能够监听传入的命令并回复它们。

mod_wsgi 可能不是适合这项工作的工具,但这很好,我只是不知道是什么。

Ubuntu 11.10, Python 2.6. Background: I have an existing Python app that is using Twisted to sit in a loop and wait for RESTful commands to come in. So the app starts up, kicks off threads that do various things, and main sets up callbacks for Twisted, then calls Twisted.reactor.run(), which blocks forever. When a request comes in, the appropriate handler is called, stuff happens, a reply is sent back.

My job is now to remove Twisted because management has decided they don't like it. We're moving to Apache as our web server.

Using the documentation, I have successfully installed and configured Apache2.0 to serve web pages. I also installed mod_wsgi, and was able to configure it and Apache to execute arbitrary Python code when a request comes in. So I'm good on that side.

What I'm missing is how to connect my Python application to the Apache/mod_wsgi bits, since the application needs to be persistent and always running. It was suggested that I open a pipe between my wsgi script and my main application, and serialize the requests that way. But it seems like this is something that should already be out there, I just don't know enough to know what to search for.

Any pushes in the right direction are greatly appreciated.

Further edit for clarity: I'm not making a webserver. The application in question is a host app that is running on a virtual machine. It happens to be controlled by a RESTful interface via HTTP. So all it needs to do is be able to listen for incoming commands and reply to them.

mod_wsgi may not be the proper tool for this job, which is fine, I just don't know what is.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

北笙凉宸 2025-01-15 11:56:52

mod_wsgi 的守护进程模式是否在您的情况下提供了足够的持久性?或者,如果您想与 Apache 分开运行主进程,那么 mod_fastcgi 怎么样?也许运行 Apache 作为反向代理也是一种选择。

Does the daemon mode of mod_wsgi offer enough persistence in your case? Or if you want to run the main process separately from Apache, how about mod_fastcgi? Maybe running Apache as a reverse proxy could be an option too.

冰雪梦之恋 2025-01-15 11:56:52

有人建议我在 wsgi 脚本和主应用程序之间打开一个管道,并以这种方式序列化请求。

这就是多处理队列的用途。

http://docs.python.org/library/multiprocessing.html

http://docs.python.org/library/multiprocessing.html#pipes-and-queues

你会如果您开始使用 Celery,您会更加高兴。

Celery 将允许您“删除 Twisted,因为管理层认为他们不喜欢它”。

然而。切换到 celery 意味着诸如“应用程序启动,启动执行各种操作的线程,并且 main 为 Twisted 设置回调,然后调用 Twisted.reactor.run(),这会永远阻塞”之类的事情都必须完全重新考虑。您现在拥有由 celery 协调的多个独立进程,而不是某些主轮询循环。

您会发现应用程序中的所有内务处理 - 线程之间的所有协调 - 回调 - 所有这些 - 都将消失。您将剩下一些执行“实际工作”的 Python 脚本和管理分布式任务队列的 Celery。

It was suggested that I open a pipe between my wsgi script and my main application, and serialize the requests that way.

That's what multiprocessing queues are for.

http://docs.python.org/library/multiprocessing.html

http://docs.python.org/library/multiprocessing.html#pipes-and-queues

You'll be even happier if you start using Celery.

Celery will allow you to "remove Twisted because management has decided they don't like it."

However. Switch to celery means that things like "So the app starts up, kicks off threads that do various things, and main sets up callbacks for Twisted, then calls Twisted.reactor.run(), which blocks forever" all have to be completely rethought. Instead of some main polling loop, you now have multiple, independent processes that are coordinated by celery.

What you'll find is all the housekeeping in your application -- all the coordination among threads -- the callbacks -- all that -- will go away. You'll be left with a few Python scripts that do the "real work" and Celery to manage the distributed task queue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文