Hi! > Are you saying performance is not the reason we use persistent handles?
It is, for databases where connection setup is expensive. Even then persistent handles are not always the best solution. But with DB, you routinely connect to one service, with one set of credentials, and need this connection constantly. With HTTP, it is rarely the case that you want to maintain the connection to the same service for an extended time (like hours or even days). > Stas, I really don't understand what's the issue here for you. The issue is that I think maintaining long-time persistent HTTP connections (I do not mean keepalive connection that serves a number of requests within the context of one workload, like browser does) is not a good idea, in fact it looks suspiciously like a DOS since many HTTP servers, including Apache, are not equipped properly to handle such model. While there may be corner cases where it may be useful, encouraging the practice looks like a mistake to me. > Youself said that HTTP is a stateless protocol, so how would a > connection in an "unclean state" look like in your opinion? Connection and protocol are different things. In connection, you could be in the middle of the protocol - i.e. sending headers, sending body, receiving headers, receiving body - and these are different states. > Curl caches connections the servers are fine with keeping alive, and I > cache curl handles grouped by the id you pass to the client constructor > and the authority of the url, that's all, nothing spooky. Caching connections within the same request and reusing them is not spooky, but caching them long term, across requests, across security domains, for extended time - is spooky. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
