On 05/02/15 09:53, Stanislav Malyshev wrote: > Hi! > >> Databases (see my pecl/pq example in the RFC), key/value stores, message >> queues, whatever you can think of. > > HTTP and databases are principally different. HTTP protocol is stateless > message-oriented protocol, and database connection protocols have very > little in common with HTTP. > >> To demonstrate to ou how it would work out over multiple requests. > > But this example doesn't demonstrate doing something that people > actually would or should do. And it also doesn't demonstrate a need for > persisting HTTP connections across requests. In fact, it may be harmful > for HTTP servers if connections were not closed when the user is done > with them but the server is forced to keep them open beyond the time > needed to serve the actual client. > >> Why do you think the connection should automatically be closed? >> That's not the default case since HTTP/1.1, except the server is >> explicitely configured to close each connection after serving. > > If the client is done with the connection, it is natural to assume it is > closed. If it's not, then client failing to finish the communication for > some reason may leave connection in wrong state and the other client may > unsuspectingly reuse it, leading to very weird results. > >>>> █ mike@smugmug:~$ time php -d raphf.persistent_handle.limit=0 -r 'for >>>> ($i=0;$i<20;++$i) {(new http\Client("curl","google"))->enqueue(new >>>> http\Client\Request("GET", "http://www.google.at/"))->send();}' >>>> >>>> 0.04s user 0.01s system 1% cpu 2.790 total >>> >>> So, the difference is microscopic even here. But with proper HTTP >>> handling - like batch requests or keepalive - it would be even less. >> >> Microscopic?! 50%?! Could you please elaborate? :) > > Sorry, I looked at wrong number, there is a difference. But if you need > to talk a lot to the same service, why not just use keepalive connection > for all your requests? As I said, sharing connections between > unsuspecting clients may lead to problems. >
Stas, we're talking in circles here :) Of course this is Keep-Alive. Keep in mind that it's curl which is working under the hood, managing alive connections for us. I just keep curl alive to take advantage of that fact. You can pass a persistent handle identifier (just a unique name) as second argument to the constructor of http\Client, so you can group related handles to max out that benefit. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php