不要完全依赖数据库可以将编辑好的信息直接从数据库缓存到数组或修改PHP文件写成变量形式

解决方案 »

  1.   

    对于访问量大的网站,可以在apache里配置缓冲啊
      

  2.   

    假设PHP+mysql的瓶颈都是388,那么要同时响应100个请求,每页上只能有4个查询,这样对一个商业软件来说是不可能的。根据这个瓶颈“PHP+mysql的并发上限”,对一个页面有10个数据库操作的系统来说,系统并发能力最多30个左右的连接,如果一个人点了几个网页,那么算到人头不也就支持10个多点的人同时上站,这样的速度根本就是“小儿科”,哪来的技术先进行?超过15个人要向上站只能 等、排队 。。 
        你看看人家Apache多快,我机器上测出每秒能接受900个左右的请求,300个人同时上站也应付自如!为什么PHP+mysql的程序这么慢,慢的没有道理,为什么要迁就这个瓶颈?以前宣传的PHP和mysql都是以快出名的,怎么快成这样子了?
      

  3.   

    这种测试,没什么意义,如果服务器足够好,直接用mysql_pconnect连接算了,把最大连接数开到 1000
      

  4.   

    "30-40个的人同时在线"这本来就是天大的笑话,你看一下 www.im286.com 其实用的是好普通的服务器,但人多的时候一秒钟同时刷新绝对超过有这个数,更不用说在线人数了。
      

  5.   

    原来是涉及到MYSQL apache PHP 的优化配置问题,
    不过我配了my.cnf的max_connections为1024,用 mysqld  --verbose检查也生效了,但测试结果仍然没变。
    不知道还需要配置那些项目才能起作用。
      

  6.   

    每页仅仅4个数据查询,也不能支持超过百人同时在线!你这是怎么得出来的?388/4? 难道每页查询数据库以后你不断开数据库连接的?
    Apache同时只接受5个连接,5 * 4 = 20 最多也不过同时访问数据库20次
      

  7.   

    我改过test.php,用“持续连接”还是“直接连接”好像的“上限”差不太多.
        我的意思是在一秒钟内,100个人同时点了某一个页面,那么4*100>388那么就会出现有部分连接需要等待,不能立刻返回,如果像oscommerce这样首页就访问数据库89次的话,有4个用户在1秒内同时点主页,那么第4个用户就不能马上得到反馈。在高峰期一个小有规模的电子商务网站在1秒钟内可能接受到的点击都小于4个的话,那这个网站肯定是无人问津,那也不用担心什么并发数量了。
        oscommerce是一个很典型的例子,你们也可以做个压力测试,安装完后点击“DVD”商品项目,居然访问了124次数据库,因此压力测试数据显示每秒处理不了3个请求。
        我脑子不好用,还是找不到合理的解释,为什么请求数和“上限”看起来关联很紧密,而且有数据可以证明,apahce/bin下面有ab这个压力测试程序,装了apache的都可以立刻测试自己的系统,用事实说话吧,如果是这个ab的测试方式导致上诉假象的话,那也可以换一种测试方法,然后得到合理的证据和解释。我觉得值得继续验证,我希望我错了,我希望我的PHP能并发的像apache那么快。都来反驳我把!
      

  8.   

    谁让你用PHP + MySQL,用ASP + SQL Server吧。
      

  9.   

    PHP可能以前比ASP快,但现在比起ASP差远了。这个我做过测试,在IIS下PHP比ASP慢多了,在Linux下更慢,还没有在Windows下跑的快。
      

  10.   

    各位同学
    缓冲,我希望大家重视这个问题,cache
      

  11.   

    把数据库当WEB服务用,真搞笑。
    如果那么写程序的话,还开发apache干什么?mysql不就可以独当一面了吗?对数据库知之甚少的同学建议去重修,我就重修过,哈归根结底,你的构架有问题
      

  12.   

    严重对你的言论产生怀疑!!!
    Apache的线程上限是255个,呵呵,你请求的速度不可能超过这个
    另外,mysql的实际速度远远不止这么多你好好测试测试