【转】Mac OS/Linux命令查询网络端口占用情况

netstat命令

netstat -an | grep 3306

3306替换成需要grep的端口号

lsof命令

通过list open file命令可以查看到当前打开文件,在linux中所有事物都是以文件形式存在,包括网络连接及硬件设备。

lsof -i:80

-i参数表示网络链接,:80指明端口号,该命令会同时列出PID,方便kill

原文:http://www.cnblogs.com/kaiye/archive/2013/05/25/3099393.html

主流PHP框架 Yii2,Laravel,CodeIgniter 性能对比

测试结果:

框架 CPU占用 Requests per second(吞吐率)
Yii2 2.0.8 99% 6826
CodeIgniter-3.1.2 99% 8600
Laravel 5.3.22 100% 704

说明:

Yii2 和 CI 用 ab 命令进行测试,总共 100000 次请求,而 Laravel 速度太慢,我不愿等,设置为前者10%共 10000 次请求。

CPU占用一列,Yii 和 CI 是 99%,是因为占用变动在96-99.5%之间,而 Laravel 的稳定在 100%。

测试环境请看之前博文:https://upliu.cc/opcache-performace.html

Opcache 开启前后性能对比

测试环境介绍

机器是一台基于 vmware 的虚拟机

CPU: cat /proc/cpuinfo 看到为 8 核 CPU,
    型号是 Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz
MEM: free 命令看到内存大小为 16G
nginx 版本为 1.11.5, worker_processes 8
php 版本为 7.0.12, fpm 进程 100 个

程序是 yii2-app-basic , HelloController.php 文件内容如下:

<?php
namespace app\controllers;

class HelloController extends \yii\web\Controller
{
    public function actionWorld()
    {
        return 'Hello, world!';
    }
}

测试命令: ab -n10000 -c100 ‘http://yii2.app.com:8090/index.php?r=/hello/world’

测试结果:

 Opcache CPU占用 Requests per second(吞吐率)
未开启 99% 520
开启 99% 5480

用 strace 追踪 php-fpm 的系统调用(strace 会严重影响性能,追踪系统调用时用的测试命令是:ab -n1000 -c100 ‘http://yii2.app.com:8090/index.php?r=/hello/world’,总请求减少为之前的10%),结果如下:

未开启 Opcache php-fpm的系统调用
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
29.99    0.512695           3    174053           fstat
18.60    0.318016           5     59611           munmap
13.98    0.238919           4     58059         3 open
13.56    0.231822           4     59235           mmap
9.70    0.165759           3     59559           close
4.83    0.082623           8     11010         4 lstat
3.46    0.059209           2     28014           read
1.14    0.019432           4      5102       100 stat
0.76    0.012930          13      1000           accept
0.66    0.011317           6      2000           chdir
0.50    0.008500           8      1005           write
0.50    0.008488           8      1001           getcwd
0.44    0.007527           8      1000           shutdown
0.41    0.006957           2      3000           setitimer
0.40    0.006795           7      1000           poll
0.37    0.006369           4      1610           rt_sigaction
0.31    0.005215           3      2000           times
0.19    0.003238           2      2000           recvfrom
0.11    0.001857           2      1001           rt_sigprocmask

开启 Opcache php-fpm的系统调用
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
26.92    0.041058           1     28015           read
15.73    0.023990           5      5160       100 stat
8.44    0.012872           6      2000           chdir
6.78    0.010336           3      3000           setitimer
6.04    0.009209           4      2132           fcntl
5.49    0.008373           8      1000           accept
5.29    0.008068          13       615         4 lstat
3.63    0.005544           3      1618           close
3.48    0.005308           3      2000           times
3.01    0.004586           5      1001           rt_sigprocmask
2.90    0.004427           4      1005           write
2.65    0.004042           4      1001           getcwd
2.39    0.003651           2      1610           rt_sigaction
2.29    0.003491           2      2000           recvfrom
1.93    0.002950           3      1000           shutdown
1.65    0.002516           3      1000           poll
0.81    0.001241           3       397           mmap
0.38    0.000582           6       100           clone

测试结果分析:

Opcache 开启前后 cpu 使用率都达到了 100% 说明系统瓶颈在 cpu。开启 Opcache 后系统调用少了很多,特别是 fstat,mumap,open,mmap,开启后,这几个系统调用可以忽略不计。Opcache 省去了每次加载和解析 PHP 脚本的开销,一次加载解析后后续请求不用去读源码,因此少了这么多系统调用。

结论:提高PHP程序的性能,最重要也最有效的方法就是开启 Opcache。

其它:  最初 fpm 配置是监听端口,吞吐率在开启Opcache前只有340左右;开启Opcache后在900左右,cpu占有80%,无法达到100%;如果请求过多,则会出现超时错误。后来改 fpm 监听 unix sock,性能一下子上来了。Yii2 开启  debug 模式后,吞吐率为 1200  左右。

保持对数字的敏感度

今天我负责维护的一个系统(基于某开源系统的二次开发),使用者那边反馈了一个bug,具体表现大致为数据错乱,本该属于A的数据确关联到B上了,ID 为 128 的数据关联到 ID 为 127 上去了。我在查阅代码的同时,使用者那边也在开源系统官方交流群里面反馈问题,使用者把信息同步给我说群里有个人提到 mysql tinyint 数据范围为 -128 到 127 改下字段类型就行了。这时我才恍然大悟,我早该想到问题出在这的,这个系统有一段时间没有进行的维护,近期也没有提交新代码,怎么这两天突然出现这种 bug 呢,本属于 128 的数据跑到 ID 为 127 的记录去,127 这个数字程序员应该很熟悉才对。

惭愧。