pfsockopen() - php 网络函数
pfsockopen()
(PHP 4, PHP 5, PHP 7)
打开一个持久的网络连接或者Unix套接字连接。
说明
pfsockopen(string $hostname[,int $port=-1[,int &$errno[,string &$errstr[,float $timeout= ini_get("default_socket_timeout")]]]]): resource这个函数的作用与fsockopen()完全一样的,不同的地方在于当在脚本执行完后,连接一直不会关闭。可以说它是fsockopen()的长连接版本。
参数
对于其参数的信息,请参考fsockopen()的文档。
参见
fsockopen()
打开一个网络连接或者一个Unix套接字连接
pfsockopen() works great on IIS/Windows7 installation, it keeps connection open which is good for performance. However, there is one caveat: when connection is broken because of physical net failure, pfsockopen() returns handle as if connection was working. Subsequent call to fwrite() returns false so you have information about error. The problem is that after physical net connection is restored the situation doesn't change: pfsockopen() still returns handle and fwrite() returns false. In other words, PHP sticks to old connection that is not working (if you use fsockopen() instead, it will connect properly). Situation goes back to normal after 30 minutes when PHP closes unused connection. The solution to this problem is to call fclose() on socket handle when fwrite() returns false.
To see if it's really a new connection, or a reused one, you can use ftell() - and see if ther's been any traffic on the connection. If it's more than 0, then it's a reused connection.
Persistent connections either in socket or databases should be used only in servers where the limits are well defined. For example, the number of allowed connections in a database must be greater than the number of Apache's processes, or the connections will be refused by the database (this will surely occur if you use persistent connections). The same may occur with socket connections. This is up to the service configuration. In my opinion, persistent connections are useful only if you have total control over the one or more servers involved, like on a heavy loaded dedicated server for example, where the little gain in performance worth the use of such connections. Never use them in a shared server.
OK, WRT to the p* functions opening a new connection when one already exists. It is my understanting that (under Apache anyways) this is on a per-process basis. If you do a 'ps auxw|grep httpd' on your server you will see more than one process. What p* does is make a p-connection on one of those processes only, the one that actually handles your request. Chances are that when you hit the page again it will be answered by a different process. I'm guessing if you keep hitting reload you'll get around to the original process again and there will be no error message or second connection open. Anyhow, this is true of all p* functions; they open not one connection per server, but one connection per server _process_.
Here is how to POST a form action to a SSL server's cgi and retrieve output with pfsockopen
Confusion arises as to when PHP starts a new connection using all the "persistent" versions of any function, and this depends entirely on how you run your PHP. In real CGI mode, that is, one process per script, persistent functions do the exact same as their "temporary" equivalents. If you have a threaded Apache MPM, this persistence will open a connection per thread, but not immediately. Think of it as a single PHP instance for each thread. If you run prefork, the MPM that forks the Apache server into several accept()ing subprocesses, you'll have one PHP instance per process. This isn't always true as I might've missed some gotchas, but in general, do know that a persistent can only try to be persistent. As for grey at greywyvern dot moc: A cronjob would be a lot better suited for this, and have it periodically update the index rather than request ~200 pages each time somebody searches, at least from what you describe it as.
鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com
免责声明:我们致力于保护作者版权,注重分享,当前被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!邮箱:344225443@qq.com)
图片声明:本站部分配图来自网络。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!
内容声明:本文中引用的各种信息及资料(包括但不限于文字、数据、图表及超链接等)均来源于该信息及资料的相关主体(包括但不限于公司、媒体、协会等机构)的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理!本站为非盈利性质站点,本着为中国教育事业出一份力,发布内容不收取任何费用也不接任何广告!)