centos 6.3+apache+php+apc+memcache 性能这么低,不知道怎么优化了。-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

centos 6.3+apache+php+apc+memcache 性能这么低,不知道怎么优化了。

kun坤 2020-06-07 00:33:20 27

阿里云的服务器

OS :CentOS release 6.3 (64bit)

CPU:4  Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz

Memory:8G

Database:mysql 5.1

PHP5.3.27 + apc + memcache


ab -n 1000 -c 50 http://***********


ab -n 1000 -c 100 http://***********


ab -n 1000 -c 300 http://***********


apc 命中率99.5


请求的PHP数据都放在缓存里(memcache),几乎没有数据库读取的问题。

接下来应该怎么优化性能。

缓存 关系型数据库 MySQL Linux PHP 数据库 Memcache
分享到
取消 提交回答
全部回答(1)
  • kun坤
    2020-06-08 11:18:17

    @南湖船老大 过来看看吧,船老大。######

    查看access日志每个请求大致花了多少时间

    代码分段加日志,检查时间究竟花在了哪里

    具体问题具体解决。

    ######回复 @len : 用了thinkphp框架,我们正在自己写的MVC构架。######回复 @都市网达 : 你现在是多少,考虑到用了框架的话应该会有100以内吧。还是得看你逻辑是不是如果有缓存的就直接取缓存了,如果是这样的还这么慢,那就自己写个不带框架的试试,如果两个差距大了那就是框架的原因了。如果不大的话可以从系统环境上去考虑。######回复 @len : 如果大于10ms应该怎么优化呢,g-zip已经开启。######回复 @都市网达 : 多少算正常,如果是有缓存的操作,正常应该是在10MS以内吧。######access日志还算是正常的。###### @eechen######

    在压测的时候,top,iostat,vmstat也要开着啊,同时监控。这么做的目的,是为了确认瓶颈是CPU,还是IO,还是带宽。服务器再牛逼,给你1M的带宽,那也卡成翔啊。

    4核8G的云主机,压到这个值不算高,但也不算低,具体要看业务是否复杂,这个还真不能随便比较。不过我感觉你这偏低了。

    如果确认数据库上的消耗比较少,就去看前端web服务器的日志,你是Apache,Apache也可以调整下进程数,反复调节观察,做到平衡。

    我优化Apache的做法除了修改参数,也会用lsof来查看一个Apache进程加载的文件,去掉不必要的Apache模块和PHP扩展。

    另外,注意看下open files有没有修改limit,TCP协议这块也可以优化。

    APC的话,仅仅对垃圾代码作用大一点,他的作用主要是opcode的优化,减少include文件的加载。如果代码架构的不错,这个APC的作用会更小。

    文件系统的优化我不懂。这块也是可以做文章的

    ######i5-3230M(双核四线程),4GB内存,64位Ubuntu14.04(Kernel3.14.5)
    1个Nginx工人进程(OpenResty1.5.8.1),8个PHP-FPM工人进程(PHP5.5.8),开启opcache. MySQL和Memcached均通过apt-get安装.

    ab -c100 -n10000 http://127.0.0.1/t.php

    测试1:进行1次mysql数据库连接和1个查询,并输出50次md5时间戳计算,RPS能达到3K+.


    测试2:进行1次memcached连接和1次set/get操作,并输出50次md5时间戳计算,RPS能达到3.7K+.

    ######回复 @eechen : @都市网达 请提供详细信息######回复 @codepat : 楼主给的信息明显不够,我也帮不上忙。######这是你的数据。@你是让你看下楼主的问题原因在哪######先不说别的,php5.3后的大版本相对5.3性能有质的提升,升级吧######说明阿里晕的服务器很渣,同样的程序你在自己的ubuntu上跑一下就可以对比出来######

    引用来自“南湖船老大”的评论

    在压测的时候,top,iostat,vmstat也要开着啊,同时监控。这么做的目的,是为了确认瓶颈是CPU,还是IO,还是带宽。服务器再牛逼,给你1M的带宽,那也卡成翔啊。

    4核8G的云主机,压到这个值不算高,但也不算低,具体要看业务是否复杂,这个还真不能随便比较。不过我感觉你这偏低了。

    如果确认数据库上的消耗比较少,就去看前端web服务器的日志,你是Apache,Apache也可以调整下进程数,反复调节观察,做到平衡。

    我优化Apache的做法除了修改参数,也会用lsof来查看一个Apache进程加载的文件,去掉不必要的Apache模块和PHP扩展。

    另外,注意看下open files有没有修改limit,TCP协议这块也可以优化。

    APC的话,仅仅对垃圾代码作用大一点,他的作用主要是opcode的优化,减少include文件的加载。如果代码架构的不错,这个APC的作用会更小。

    文件系统的优化我不懂。这块也是可以做文章的

    apache 2.2.24,采用mpm_prefork模式

    <IfModule mpm_prefork_module>
        ServerLimit         2048
        StartServers          5
        MinSpareServers       3
        MaxSpareServers      30
        MaxClients          2048
        MaxRequestsPerChild   0
    </IfModule>



    这里的参数有调整,程序是使用thinkphp框架,我是比较讨厌用TP的,但是不是由我来决定的。

    ######

    引用来自“eechen”的评论

    i5-3230M(双核四线程),4GB内存,64位Ubuntu14.04(Kernel3.14.5)
    1个Nginx工人进程(OpenResty1.5.8.1),8个PHP-FPM工人进程(PHP5.5.8),开启opcache. MySQL和Memcached均通过apt-get安装.

    ab -c100 -n10000 http://127.0.0.1/t.php

    测试1:进行1次mysql数据库连接和1个查询,并输出50次md5时间戳计算,RPS能达到3K+.


    测试2:进行1次memcached连接和1次set/get操作,并输出50次md5时间戳计算,RPS能达到3.7K+.

    你这里的测试是本地,不要担心带宽的问题,而且 t.php应该只是一个普通数据库操作文件吧,不过我可以试试将程序迁移到nginx。######回复 @eechen : 你的建议非常对好,其实我对nginx来处理PHP一直不带好感,一般用nginx来做代理,PHP使用apache处理后端。我想阿里云的性能也是有影响的。######所以我也建议你先在本地进行测试,避免带宽带来的影响。就PHP而言,nginx/php-fpm的性能并不比httpd/libphp5.so的性能高,只是php-fpm把PHP剖离出来更方便扩展和管理。######
    vps ubuntu 1G+512M java+nginx+tomcat7+memcache 如果是centos性能会更好一些
    Server Software:        nginx
    Server Hostname:        cms.zendlab.com
    Server Port:            80
    
    
    Document Path:          /apps/api/book.jsonp?method=list
    Document Length:        31150 bytes
    
    
    Concurrency Level:      50
    Time taken for tests:   1.046 seconds
    Complete requests:      1000
    Failed requests:        0
    Write errors:           0
    Total transferred:      31789000 bytes
    HTML transferred:       31150000 bytes
    Requests per second:    955.90 [#/sec] (mean)
    Time per request:       52.307 [ms] (mean)
    Time per request:       1.046 [ms] (mean, across all concurrent requests)
    Transfer rate:          29674.98 [Kbytes/sec] received 
     
    



    0 0
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题