那么每次访问PHP页面时,HTTP服务器都会重新解释一遍PHP源代码吗?
那是必然了,脚本语言一般都做成解释型的,虽然执行效率低了,但是却方便开发,不用每次都编译,那服务器生成动态页面的效率是不是太差了.
很差吗?脚本语言本来就不应该做太复杂的数据运算,它不是为这个设计的,绝大多数网站都是采用脚本语言开发的,如果效率真的那么差,恐怕它早就被淘汰了。

解决方案 »

  1.   

    这应该是web服务器的事,因为你运行网站的时候,并没有php这个进程,一切的操作都是web服务器来执行的,包括使用内存缓存等
      

  2.   

    其实解释执行php的速度比编译后执行差很多,访问量很少的情况下是看不出来的.看来zend是先行一步,不过商业化太重了,zend encode是很贵的,而且只是编译成类似java的中间代码.
    好像也有一些业余的php compiler,不过离成熟还很遥远.
      

  3.   

    瓶颈不在php,这种执行完就跑的方法恰恰能对付很大的访问量,因为http是非持续连接,访问量再大就要考虑其他技术了,这就超出范围了;一台中等的服务器一天能承受10w级别的访问量,如果没有数据库连接可以承受100w级别的访问
    生成Html不需要多少复杂的运算,那些复杂的算法一般都交给数据库勒,增加内存缓存等功能会增加复杂度容易使程序出错
      

  4.   

    生成http页面运算量不少,主要是脚本比较多的情况,就像其他解释器一样使用词法分析器匹配关键字和符号,再调用语法分析器分析逻辑和排错,最后才能真正执行脚本.
    执行"c=a+b"这样的脚本,解释执行的效率和编译后执行的效率差距极大,当然这是极端情况.
    要不是考虑编写复杂度,调试困难和稳定性,像ISAPI/NSAPI那类插件就非常高效.
    基于Apache的应该可以使用mod,我注意到百度就做了一个mod_baidu,还有为百度贴吧写的mod_forum.
    而google为了高效,自己写了个http服务程序(GWS).
    这类程序应该都是本地代码级的,不过要为Apache写mod还是很困难的,资料也很少.
    能把php编译成真正的本地代码效率应该比写mod差太多,但编写起来更容易,出错更少.