Element is not clickable at point (321, 17). Other element would receive the click
使用 Codeception acceptance 测试,启用 WebDriver 模块,浏览器使用 chrome 时出现这个错误。把浏览器换为 firefox 就 OK 了。
参考链接:http://stackoverflow.com/questions/11908249/debugging-element-is-not-clickable-at-point-error
PHP直播写代码 – 用YII2开发开源问答系统
直播间:http://live.bilibili.com/2186055
固定直播时间:工作日 8:00 – 9:00 周末 8:00 – 10:00
不固定直播时间:工作日 22:00 – 24:00 周末 13:00 – 15:00、 22:00 – 24:00
【转】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
MAC 设置软件开机启动
打开 系统偏好设置 – 用户与群组 – 登录项,然后选择要开机启动的软件。
注:严格来说其实并不是开机启动,而是登录时启动。
主流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
php5.6 和 php7 性能对比
测试结果:
php版本 | CPU占用 | Requests per second(吞吐率) |
---|---|---|
5.6.27 | 99% | 3100 |
7.0.12 | 99% | 5480 |
测试环境请看前一篇博文: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 这个数字程序员应该很熟悉才对。
惭愧。