PHP 中与后端服务的共享/池连接
当我让 PHP 与各种后端服务（例如 Amazon S3 或任何其他随机 Web 服务 - 我想要一个通用解决方案）对话时，我试图找出最小化资源利用率的最佳方法。理想情况下，我希望有一个到后端的持久连接（或者可能是一个小的持久连接池）并带有一些缓存，然后让所有 PHP 任务共享它。出于这个问题的目的，我们可以将其视为只读。对我来说，如何在 PHP 中执行此操作并不明显。有一些特定于数据库的东西，例如 mysql_pconnect()，但这并不真正适合我。
我的一个想法似乎不太理想（但仍然比让每个请求创建和销毁新连接更好）是使用本地缓存代理（在单独的进程中），它可以有效地进行池化和缓存。 PHP 仍然会为每个请求打开和关闭连接，但至少它会是本地进程，所以它应该更快一点（并且会减少后端的负载）。但这种疯狂似乎没有必要。一定有更好的办法。这在其他语言中很容易。请告诉我我错过了什么！
I'm trying to figure out the best way to minimize resource utilization when I have PHP talking to various backend services (e.g. Amazon S3 or any other random web services -- I'd like a general solution). Ideally, I'd like to have a single persistent connection to the backend (or maybe a small pool of persistent connections) with some caching, and then have all of the PHP tasks share it. We can consider it all read-only for the purposes of this question. It's not obvious to me how to do this in PHP. There's the database-specific stuff like mysql_pconnect(), but that doesn't really do it for me.
One idea I've had, which seems seems somewhat suboptimal (but is still better than having every single request create and destroy a new connection) is to use a local caching proxy (in a separate process) that would effectively do the pooling and caching. PHP would still be opening and closing a connection for every request, but at least it would be to a local process, so it should be a little faster (and it would reduce load on the backends). But it doesn't seem like this kind of craziness should be necessary. There's gotta be a better way. This is easy in other languages. Please tell me what I'm missing!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
各种网络技术之间存在着巨大的意识形态脱节。有些本质上是在后台全职运行的守护进程，并自行处理传入的请求。因为有一个进程始终在运行，所以您可以拥有一个已打开的现有工作连接池。
PHP（和普通的 CGI 脚本）没有后台守护进程。每次收到请求时，PHP 解释器都会从头开始启动，编译脚本并运行字节码。没有什么坚持。支持持久连接的 PHP 数据库函数在Web 服务器子级别建立连接（即附加到 Apache 进程的 mod_php）。这并不完全是一个连接池，因为您只能看到附加到您自己的进程的持久连接。
如果没有后台进程或类似进程来分配资源，您将无法获得真正的连接池。
请记住，大多数到大多数服务的新连接都不是重量级的，并且重量级的非数据库连接可能对连接的概念不友好水池。
在您考虑编写自己的基于 PHP 的守护程序来处理此类内容之前，请记住它可能已经是一个已解决的问题。 Python 提出了名为 WSGI 的东西，Ruby 中也有类似的实现，称为 Rack。 Perl 也有一些非常相似的东西，但我记不起它的名字了。快速浏览一下 Google 并没有显示任何 WSGI 的 PHP 实现，但这并不意味着它们不存在......
There's a large ideological disconnect between the various web technologies. Some are essentially daemons that run full-time in the background, and handle requests passed in on their own. Because there's a process always running, you can have a pool of already open existing working connections.
PHP (and normal CGI scripts) does not have a daemon behind the scenes. Every time a request comes in, the PHP interpreter is started up with a clean slate, compiles the scripts, and runs the bytecode. There's no persistence. The PHP database functions that support persistent connections establish the connection at the web server child level (i.e. mod_php attached to an Apache process). This isn't exactly a connection pool, as you can only ever see the persistent connection attached to your own process.
Without having a daemon or similar process sitting behind the scenes to hand out resources, you won't get real connection pooling.
Keep in mind that most new connections to most services are not heavy-weight, and non-database connections that are heavy-weight might not be friendly to the concept of a connection pool.
Before you think about writing your own PHP-based daemon to handle stuff like this, keep in mind that it may already be a solved problem. Python came up with something called WSGI, with a similar implementation in Ruby called Rack. Perl also has something remarkably similar but I can't remember the name of it off the top of my head. A quick look at Google didn't show any PHP implementations of WSGI, but that doesn't mean they don't exist...
由于 S3 和其他 Web 服务使用 HTTP 作为传输，因此您不会从缓存连接中获得显着的好处。
Because S3 and other webservices use HTTP as their transport, you won't get a significant benefit from caching the connection.