happyhacker 的博客

BasicAuth简介

2018-07-02T18:23:51+08:00

我在维护的一个内部服务用到了 BasicAuth 的认证方式, 但总是有人不断的问我要怎么用, 这里详细的说一下.

使用场景

要知道 BasicAuth 的使用场景, 它是最简单的一种认证方式, 说白了就是用户名+密码, 这种方式有很多问题, 比如它通过网络发送用户名和密码, 而这些都是以一种很容易解码的形式表示的. 虽然它是用 base64_encode 加密过了, 但这种加密的作用也仅仅是让可信任的用户不太可能在进行网络观测时无意中看到密码, 而不能防止恶意用户. 所以也仅限在一些安全要求不是那么高的场景下使用.

原理和实现

其次要明白 BasicAuth 的原理和实现. 简单来说, 它是检查你的 Headers 中的Authorization. 从中解析出 username 和 password, 和服务器保存的进行对比, 如果一致则通过, 否则返回401/403状态码, 表示客户端没有携带或携带了错误的认证信息（具体可参见我的文章HTTP 状态码 401 和 403 深度解析).

使用方法

下面详细说一下怎么调用一个有 BasicAuth 认证的服务. 比如你的 username 是 zhangsan, password是 helloworld(当然不建议用这种太简单的密码), 那么你只需要在你调用接口时在 Header 里加上一个 Header

Authorization: Basic $(base64_encode({username}:{password}))

即可. 更具体的, 也就是

Authorization: Basic emhhbmdzYW46aGVsbG93b3JsZA==.

具体到 postman就更简单了, 它支持多种认证方式, 当调用需要BasicAuth 认证信息的接口时, 如图所示选择并填写即可.

具体到某一种语言, 就不太能全面覆盖了, 如果你用了某种封装好的客户端, 比如 PHP 的 guzzlehttp 或 Java 的 OKHttp之类, 它们肯定是会像 postman 一样对这种应用相当广泛的认证方式直接支持的. 如果你用的是自己封装的客户端,那么就可以按照前面说的自己生成Authorization即可.

Ubuntu下重新打包预编译安装的PHP

2018-06-29T10:33:06+08:00

起因

写这篇文章的起因是要安装Swoole，而它又依赖php_sockets扩展，因为我是通过apt安装的php7.2，没办法直接重新编译，所以就找到了方法，这里记录一下。

依赖

Ubuntu/Debian的打包工具

sudo apt install devscripts

重新打包PHP7.2需要的依赖

sudo apt build-dep php7.2

下载源码

sudo apt source php7.2

这里要注意一点，Ubuntu默认不打开deb-src段，也就是默认情况下你在apt-get source下是找不到任何东西的。所以需要在/etc/apt/sources.list中删除相应的deb-src的注释。然后执行sudo apt update更新本地缓存。

更改配置

今天终于知道为什么很多流行的项目源码目录下总是有一个debian目录了，原来是给Debian打包用的配置。所以给PHP打包也不例外，这里就不说具体怎么修改了，因为如果自己编译过PHP，很容易就能找到需要修改哪里。

更新版本号

这个步骤是可选的，简单说就是你更新了这个包，如果你要发布它，那它肯定不能和当前已经发布的包同名。
做法是执行dch -i，这样就会把版本号的最后一位加1。例如当前版本是7.2.5-0ubuntu0.18.04.1, 执行之后就是7.2.5-0ubuntu0.18.04.2，当然这时会打开一个交互界面让你填一些类似git commit时的Message。

重新打包

这一步很简单，就是执行一下debuild。我试了一下在源码根目录或者在debian目录下都是没问题的。应该是脚本做了容错处理。

值得注意的是，不能用sudo执行debuild，该命令默认使用fakeroot执行。而且你可以指定DEB_BUILD_OPTIONS=nocheck来跳过编译选项的检查，我觉得还是稳妥一些好，所以就不加任何选项的执行了。

打包完成

打包完成之后会生成*.deb包。看到它你一定知道下一步怎么做了。

安装新包

其实我从执行debuild开始写这篇记录，到现在它还没有执行完。

sudo dpkg -i 7.2.5-0ubuntu0.18.04.2.deb

后记

这篇记录看起来是为了重新打包预编译的包，以自定义一些编译选项，其实本质上就是一个包的maintainer的工作过程，只不过这里少了发布过程。这里是处理PHP的包，读者们也可以举一反三，根据自己的需求定制一些别的包。

谈谈PHP-FPM模式下的MySQL持久连接

2018-05-17T01:09:31+08:00

闲来无事研究一下PHP的MySQL持久连接问题。在mysql扩展的年代，应该用的是mysql_pconnect，可是那时候我还没有开始接触PHP，　所以我们直接上PDO。

首先说一下本次测试用的环境。

关键还要看一下PHP的配置。

注意其中的最重要的参数pm.max_children=1，　这决定了只能有一个FPM的worker进程来处理所有请求。这样把问题简化更容易发现特征。

我们知道，　PHP的FPM有一个master进程和若干个worker进程，而worker进程并不是像最早的fastcgi一样每次处理完一个请求之后就销毁，下次再来请求需要重新启动。也就是说一个worker进程是可以处理多个请求的。这给“持久连接”提供了理论基础。那么到底它能不能支持持久连接呢？如果支持持久连接，它的特征又是什么呢？下面直接上代码。

我在之前的文章里也提到过MySQL的general_log，按这里的描述配置一下就可以很清晰的看到哪个连接在请求服务器了。

反复执行curl http://fpm.org/index.php（我给fpm.org配置了hosts），就可以看到不断变化的lastInsertId了。但这不是重点，要看两个现象。

用root账户登录mysql，执行show processlist;可以看到类似如下的输出：

可以看到，有两个客户端和服务器保持了连接。是谁呢？第一个是Ubuntu（其实是Debian）维护的MySQL包自带的默认管理员用户，其实表示的就是当前的这个MySQL cli连接。另外一个当然就是刚才调用curl通过PHP的pdo创建的了。

现在再来看general_log，

可以看到多次请求服务器端都是同一个线程ID（14）. 参考这里

那么怎么验证它是由当前这个FPM的worker维持的呢？很简单，重启一下FPM再看它有没有变化就知道了。

sudo systemctl restart php-fpm.service

可以看到一个新的worker已经在工作了。现在重新访问刚才的地址

先再去执行一下show processlist;

可以看到14已经不在了。因为维持14这个连接的fpm worker已经挂了，当然对应的服务器的线程也已经销毁了。但15出现了。那么这几次请求用的是不是15呢？

当然是。

所以结论很明显了，在FPM模式下是可以使用mysql持久化连接的。
~~所以理论上也可以实现MySQL连接池。有时间可以研究一下。~~ 想了想是没有办法实现连接池的, 因为一个worker只能维持一个长连接,无法和别的worker共享, 只能通过配置pm.max_children来让FPM维持的长连接没有那么多不要超过MySQL的最大连接数.

不过这是一个危险操作，因为你也看到了，我在写这篇文章的过程中在没有手动重启FPM进程之前这个长连接是一直保持的，而如果这个fpm进程是空闲的，那么这个连接就是被浪费的。这有可能导致大量无用的连接占用MySQL的连接数，而连接数是有上限的，超过之后就无法再建立新的连接，导致后续的连接失败。所以必须设置长连接数的上限，同时保证worker空闲一段时间后退出，（使用pm.max_spare_servers实现）或者再处理若干次请求之后重新启动（通过pm.max_requests实现），以保证MySQL的正常连接数。

Debian执行apt update失败解决方案

2018-05-09T20:19:13+08:00

我的一个Debian虚拟机最近在执行apt update时总是报这个错误

我猜测是本地时间和mirror的时间不同导致的(本地时间滞后, 导致校验远端Release文件失败). 我认为可以通过设置正确的本地时间来解决.

果然

而现在的时间是5月9号了.

当然是通过ntp服务器而不是手动设置.

果然时间正确之后更新正常了.

查看PHP-FPM进程占用内存大小

2018-05-07T14:12:39+08:00

1. 按FPM进程实际占用内存大小排序

ps -ylC php-fpm --sort:rss

这样的结果是按KB大小显示的, 而ps命令本身不支持将其转换为按MB显示, 所以需要使用awk

ps -ylC php-fpm --sort:rss | awk 'NR>1 {$8=int($8/1024)"M";}{ print;}'

2. 查看所有FPM进程占用内存的平均值

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

这样计算完之后就可以根据自己机器内存的大小设置合适的pm.max_children的值了.

HTTP状态码401和403深度解析

2018-04-02T14:12:30+08:00

一直只是知道401和403都是拒绝访问的意思, 但没有仔细研究它们之间准确的区别, 现在详细记录一下.

表面上是这样

401 Unauthorized
403 Forbidden

从w3.org的解释来看:

作为非英语国家的我们而言, 可能不太能发觉这两个描述中的问题, 只是能看明白401是没有带认证信息或者带了错误的认证信息, 这时客户端可以修改认证信息进行重试; 而403是客户端带了正确的认证信息, 但服务器认为这个认证信息对应的用户是没有对应资源的访问权限的, 因此, 在向管理员获取相关权限之前, 是没有重试的必要的.

但实际上这个描述中忽视了两个单词: Authorized和Authenticated.

这样看就很明显了, 前者指的是"用户被允许/授权做某事", 而后者只是表示"用户是认证用户".

举个简单的例子, 在一般的后台系统中, 用户一般是通过LDAP或类似系统导入的, 也即是所有可以登录后台系统的用户都是"Authenticated"的, 他们有自己的Credentials. 但后台系统也都会有很详细的权限管理机制, 你虽然是认证用户, 但恐怕大多数资源你还是无法访问, 这时你就是"Unauthorized"的了.

所以这样看, 401的正确解释应该是"Unauthenticated", 而且在HTTP Authentication: Basic and Digest Access Authentication中需要带的请求头也应该是Authentication而不是Authorization.

这个是历史遗留问题了, 估计以后也不会有什么改变, 但我们还是需要知道这个问题, 免得在使用时混淆了401和403.

参考: 403 Forbidden vs 401 Unauthorized HTTP responses

Python setup.py 卸载包

2018-03-07T17:22:05+08:00

不是很了解 Python的生态环境, 但知道现在主流的包管理工具是 pip, 而原来是 setup.py, 本质上 setup.py 是读取 requirements.txt 从而获取该包需要的依赖, 然后把它们安装在本地, 但它的问题是没有办法完整的卸载.

python setup.py install 爽完了发现这个包并不能满足需求, 或者无法执行, 要卸载?不好意思, 只有两个命令, 一个是 install, 一个build, 没有卸载选项.

一个 workaroud 是重新安装一次, 加上一个选项--record让它这次把它创建的文件打印到一个文件里, 然后就可以欢乐的删除了.

python setup.py install --record rubbish.txt
cat rubbish.txt | xargs rm -rf

参考: python setup.py uninstall

Docker 开发环境中使用 MySQL general_log

2018-03-07T15:23:12+08:00

有了 docker 可以快速的创建一个 mysql 实例,

db:
        image: mysql
        restart: always
        environment:
            MYSQL_ROOT_PASSWORD: iampassword
        ports:
            - 3306:3306
        volumes:
            - ./env/mysql/data:/var/lib/mysql
            - ./env/mysql/conf:/etc/mysql/conf.d

因为是开发环境, 所以我希望 MySQL 能尽可能多的告诉我更多的信息, 也就是能记录详细的日志, 可以在 mysql 控制台执行以下语句:

SET global log_output = 'file';
SET global general_log_file='/var/log/mysql/query.log'; 
SET global general_log = on;

这样, 日志就打印到了容器中/var/log/mysql/query.log中, 至于你想到容器中查看日志还是在本地查看, 完全看你喜好. 如果想在容器中看

docker exec -it centos_db_1 tail -f /var/log/mysql/query.log

如果想在本地看, 就在 docker-compose.yml中, 把上面db段修改成

db:
        image: mysql
        restart: always
        environment:
            MYSQL_ROOT_PASSWORD: iampassword
        ports:
            - 3306:3306
        volumes:
            - ./env/mysql/data:/var/lib/mysql
            - ./env/mysql/conf:/etc/mysql/conf.d
            - ./env/log/mysql:/var/log/mysql

这样一个不好的地方是当容器重启后上面的三个SET语句都会失效, 如果想永久的改变配置, 就需要把这段配置放在 my.cnf中

[mysqld]
log_output = file
general_log_file = /var/log/mysql/query.log
general_log      = 1

这样既不用提交镜像, 又能保存配置咯.

搭建 docker-registry

2018-03-05T16:13:22+08:00

准备工作

Ubuntu 16.04(with docker installed)

步骤

1. 安装必要的包

sudo apt install -y docker-compose apache2-utils curl

2. 创建相关目录

mkdir /docker-registry
mkdir  /docker-registry/data
mkdir /docker-registry/nginx
chown root:root /docker-registry
cd /docker-registry

3. 创建 `docker-compose.yml`

nginx:
  image: "nginx:1.9"
  ports:
    - 443:443
  links:
    - registry:registry
  volumes:
    - /docker-registry/nginx/:/etc/nginx/conf.d
registry:
  image: registry:2
  ports:
    - 127.0.0.1:5000:5000
  environment:
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
  volumes:
    - /docker-registry/data:/data

执行docker-compose up, 就会看到一堆信息, 没有看到错误提示的话就是安装成功了.

4. 如果是在生产环境, 还是有必要让它保持后台运行

方案可以选择 systemd 或 supervisord, 这里提供 systemd 的方案

[Unit]
Description=Starting docker registry

[Service]
Environment= MY_ENVIRONMENT_VAR = /docker-registry/docker-compose.yml
WorkingDirectory=/docker-registry
ExecStart=/usr/bin/docker-compose up
Restart=always

[Install]
WantedBy=multi-user.target

5. 修改 Nginx 配置

# /docker-registry/nginx/regstry.conf
upstream docker-registry {
  server registry:5000;
}

server {
  listen 443;
  server_name myregistrydomain.com;

  # SSL
  # ssl on;
  # ssl_certificate /etc/nginx/conf.d/domain.crt;
  # ssl_certificate_key /etc/nginx/conf.d/domain.key;

  # disable any limits to avoid HTTP 413 for large image uploads
  client_max_body_size 0;

  # required to avoid HTTP 411: see Issue #1486 (https://github.com/docker/docker/issues/1486)
  chunked_transfer_encoding on;

  location /v2/ {
    # Do not allow connections from docker 1.5 and earlier
    # docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents
    if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
      return 404;
    }

    # To add basic authentication to v2 use auth_basic setting plus add_header
    # auth_basic "registry.localhost";
    # auth_basic_user_file /etc/nginx/conf.d/registry.password;
    # add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

    proxy_pass                          http://docker-registry;
    proxy_set_header  Host              $http_host;   # required for docker client's sake
    proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_read_timeout                  900;
  }
}

重启服务使配置生效 sudo systemctl restart docker-registry
执行curl http://localhost:5000/v2/, 如果正常, 应该输出{}

6. 配置认证信息

cd /docker-registry/nginx
htpasswd -c registry.password mydocker
New password:
Re-type new password:
Adding password for user mydocker

修改 nginx 配置(删除相应行前面的注释)

auth_basic "registry.localhost";
auth_basic_user_file /etc/nginx/conf.d/registry.password;
add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

重启服务使配置生效 sudo systemctl restart docker-registry
执行curl http://localhost:443/v2/, 会提示401 Authorization Required

把刚刚创建的用户名和密码加上会得到正确的返回结果

curl http://mydocker:123456@localhost:443/v2/ 结果是{}

7. 配置证书

cd /docker-registry/nginx
# 生成一个 root key
openssl genrsa -out dockerCA.key 2048
# 生成根证书( ComonName 写你的域名, 比如域名是 registry.abc.com, 这里就写 registry.abc.com)
openssl req -x509 -new -nodes -key dockerCA.key -days 10000 -out dockerCA.crt
# 生成 server key, 在 nginx 的配置ssl_certificate_key中引用
openssl genrsa -out domain.key 2048
# 申请一个新证书( ComonName 写你的域名, 比如域名是 registry.abc.com, 这里就写 abc.com)
openssl req -new -key domain.key -out docker-registry.com.csr
# 给证书签名
openssl x509 -req -in docker-registry.com.csr -CA dockerCA.crt -CAkey dockerCA.key -CAcreateserial -out domain.crt -days 10000

因为我们生成的是一个"自签名"证书, 所以是无法被其他证书发布机构认证的, 也就是必须让客户端强制信任该证书.

在宿主机上执行

cd /docker-registry/nginx
cp dockerCA.crt /usr/local/share/ca-certificates/
update-ca-certificates && service docker restart && service docker-registry restart
curl https://mydocker:123456@docker-server.com/v2/
# 结果应该是
{}

然后手工把自签名证书发布给需要的客户端,

scp dockerCA.crt ja@192.168.0.59:/usr/local/share/ca-certificates
ja@192.168.0.59's password:
dockerCA.crt 100% 1302 1.3KB/s 00:00

在客户端上, 执行

update-ca-certificates && service docker restart
#test login to fresh created repository:
docker login https://docker-server.com
Username: mydocker
Password:
Login Succeeded

8. 在客户端上测试 container 的功能

docker run -it ubuntu # 从中心 library 下载并执行 ubuntu
#re-tag images DOMAIN-NAME/NEW-TAG
docker tag ubuntu docker-server.com/test-image # 给已有container重新打 tag
#push image to repository:
docker push docker-server.com/test-image # push 到新建的 registry
docker rmi -f docker-server.com/test-image # 删除本地镜像
docker pull docker-server.com/test-image  # 从新的 registry 拉取镜像

搭建 Docker 开发环境----安装 OpenResty 和 PHP7(基于 centos7)

2018-03-05T13:48:42+08:00

openresty

安装 openresty

yum -y install yum-utils
yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
yum -y install openresty

检查openresty 相关的包

yum --disablerepo="*" --enablerepo="openresty" list available

nginx 日志

./env/openresty/nginx/log:/usr/local/openresty/nginx/logs
./env/openresty/nginx/vhost:/usr/local/openresty/nginx/conf/vhost

php7.1

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
yum -y install php71w-{pecl-redis,mbstring,pdo,mcrypt,mysqlnd,gd,common,cli,imap,intl,devel,json,ldap,xml,fpm,opcache}

php errorlog

./env/php/fpm/log:/var/log/php-fpm/error.log
./env/php/fpm/php-fpm.conf:/etc/php-fpm.conf
./env/php/fpm/:/etc/php-fpm.d
./env/php/php.d/:/etc/php.d
./env/php/php.ini:/etc/php.ini

关于wkhtmltopdf，你一定想知道这些

2018-02-28T17:20:39+08:00

前言

如果你有 Markdown 或者 HTML 转到 PDF 的需求, 有非常大的可能你选了一圈方案, 最后找到了大名鼎鼎的wkhtmltopdf. 但找到它之后并没有解决所有问题, 相反, 它会带来更多的问题.
首先说一下它的优点:

由于是基于 WebKit, 所以渲染结果和 Chrome( 包括其他基于 Chromium的浏览器几乎完全一致)
可以和前端公用一套 CSS 样式, 结果还是体验的一致性
支持大量的定制, 包括页头页脚, 页码, 目录等等, 后面会详细说

再来说一下缺点:

对特别长的表格支持有问题. 其实原因还是来自 WebKit 引擎, 因为WebKit本身是用来渲染网页的, 而网页是不需要上下分页的, 所以引擎本身并不支持表格跨页显示, 需要做一些特殊处理, 划重点了.
对于特别宽的表格, 如果不做处理, 它会被横向截断，同时会在表格下方出现一个 scrollbar, 但尴尬的是这个 scrollbar 不能拖动, 因此也就无法解决完整显示的问题.

所以, 优点很明显, 缺点也很明显. 而且通常如果你有需求生成 PDF, 那多数情况下是有表格的, 不解决这个问题, 这个方案就无法实施。

实践

下面让我们通过实验一步步解决上面的两个大问题.

长表格

~~这里我简单写了一长段表格, 然后用 MacDown 编辑器把它导出为 html, 这里只是用来说明问题, 所以就没有用我实际在生产环境使用的 Parsedown.~~写着写着觉得还是用代码能说的更清晰一些，
原始 markdown 文件和 html 文件就不贴在这里了, 可以查看phpwkhtmltopdf.

在 article 目录里执行
wkhtmltopdf longtable.html longtable-01.pdf

生成的 PDF 在分页处如下的效果

很明显可以看到表头重复出现了. 其实实际的问题不止如此, 如果单元格很宽导致换行, 很大概率会和重复显示的表头重叠.
我翻看了不下100个网页, 花费了大量时间最终找到了解决方案

thead {
    display: table-row-group;
}

解决了表头重复和文字重叠的问题.

有所改善, 但还是明显的发现表格的一行被切成了两部分.
下面这个就是如果你搜索这个问题最经常看到的答案了

tr {
    page-break-before: always;
    page-break-after: always;
    page-break-inside: avoid;
}

于是, 变成了这样子

长表格的问题到此解决.

宽表格

同样我将 markdown 文件和 HTML 文件放在了 github 上.
不加特殊处理, 得到的表格将是这样的

这是因为默认的样式中并没有

table {
    word-wrap: break-word;
}

的设置. 我这里的例子举的有些不合理, 因为不会全是一样长的单元格宽度, 实际情况总会有长有短, 当同一列中存在一个很长的单词(或者根本不是单词, 而仅仅是很长的连起来的无意义的字符串, 像本例中那样), 该列单元格的最短列宽就会以它为准. 这样导致表格的总宽度很容易超出页面限制.

因为word-wrap 控制的是有多个单词的情况, 如果只有一个单词, 它是不做处理的. 所以需要另外加一个样式

table td {
    word-break: break-all;
}

这样的结果就是所有表格都完整的展示出来了.

其他选项

提到 wkhtmltopdf 的选项也真是让人头疼, 我本来是用了snappy和它推荐的二进制包, 所有东西都准备好了, 一个问题一直解决不了: 我已经安装了宋体, PDF 的正文中的宋体也可以正常显示了, 但唯独 header/footer 里面的中文字体死活都出不来. 因为我的需求是要有页眉和页脚, 当然也要有相应的 header-line和footer-line, 如果用HTML 来填充 header, 那么 header-line 就会消失, 这时如果用 html 中的<hr>来代替, 又会看起来很奇怪, 后来发现直接调用二进制文件加上相应的选项在相同的机器上可以得出我需要的结果, 那么问题就很清楚了, 问题出在这个 snappy 上, 于是我一气之下直接用 PHP 的shell_exec简单封装了一下 wkhtmltopdf, 简直不能更好用, 所有问题迎刃而解.

总结

宽度的问题其实在网页设计里面更常见, 我不是专业的前端, 所以对相应的样式比较陌生, 导致花了一些时间. 但分页的问题真是困扰了每个用过 wkhtmltopdf 的人, 随便一搜, 几乎全是关于这个问题, 但没有一个人真正的给出普适的真正可用的解决方案. 本文给出了我自己的一些经验, 供大家参考.

MySQL 简单性能测试记录

2018-02-28T17:15:53+08:00

机器配置:

CPU: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
Memory: 8GB
MySQL: 5.7.21-0ubuntu0.16.04.1 (Ubuntu)

准备工作:

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=select \
--max-requests=0 --percentile=95 prepare

1. 读取性能测试

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=select \
--max-requests=0 --percentile=95 run

结果:

OLTP test statistics:
    queries performed:
        read:                            4248201
        write:                           0
        other:                           0
        total:                           4248201
    transactions:                        4248201 (70801.29 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 4248201 (70801.29 per sec.)
    other operations:                    0      (0.00 per sec.)

Test execution summary:
    total time:                          60.0017s
    total number of events:              4248201
    total time taken by event execution: 5998.0902
    per-request statistics:
         min:                                  0.03ms
         avg:                                  1.41ms
         max:                                266.43ms
         approx.  95 percentile:               2.72ms

Threads fairness:
    events (avg/stddev):           42482.0100/686.55
    execution time (avg/stddev):   59.9809/0.00

可以看到差不多7万的 QPS

2. 写入性能测试

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=insert \
--max-requests=0 --percentile=95 run

OLTP test statistics:
    queries performed:
        read:                            0
        write:                           49227
        other:                           0
        total:                           49227
    transactions:                        49227  (817.14 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 49227  (817.14 per sec.)
    other operations:                    0      (0.00 per sec.)

Test execution summary:
    total time:                          60.2432s
    total number of events:              49227
    total time taken by event execution: 6022.6811
    per-request statistics:
         min:                                 29.59ms
         avg:                                122.35ms
         max:                               1234.17ms
         approx.  95 percentile:             357.95ms

Threads fairness:
    events (avg/stddev):           492.2700/8.26
    execution time (avg/stddev):   60.2268/0.03

可以看到就只有800多的 QPS 了, 远远低于简单查询.

3. 更新(带索引)

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=update_key \
--max-requests=0 --percentile=95 run

结果

OLTP test statistics:
    queries performed:
        read:                            0
        write:                           21942
        other:                           0
        total:                           21942
    transactions:                        21942  (363.68 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 21942  (363.68 per sec.)
    other operations:                    0      (0.00 per sec.)

Test execution summary:
    total time:                          60.3338s
    total number of events:              21942
    total time taken by event execution: 6012.0994
    per-request statistics:
         min:                                 33.29ms
         avg:                                274.00ms
         max:                               2546.19ms
         approx.  95 percentile:             629.71ms

Threads fairness:
    events (avg/stddev):           219.4200/6.41
    execution time (avg/stddev):   60.1210/0.04

4. 更新(不带 key)

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=update_nokey \
--max-requests=0 --percentile=95 run

结果:

OLTP test statistics:
    queries performed:
        read:                            0
        write:                           28065
        other:                           0
        total:                           28065
    transactions:                        28065  (464.81 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 28065  (464.81 per sec.)
    other operations:                    0      (0.00 per sec.)

Test execution summary:
    total time:                          60.3791s
    total number of events:              28065
    total time taken by event execution: 6034.7862
    per-request statistics:
         min:                                 32.02ms
         avg:                                215.03ms
         max:                               1426.55ms
         approx.  95 percentile:             574.59ms

Threads fairness:
    events (avg/stddev):           280.6500/8.18
    execution time (avg/stddev):   60.3479/0.06

可以看到, update_nokey 比 update_key 略微高一些, 这也证明了对于更新频繁的表, 不要设置太多的索引的正确性.

4. 删除

sysbench --mysql-db=db_test \
--mysql-port=3306 --db-driver=mysql --mysql-user=root \
--mysql-password=root --test=oltp --oltp-table-size=10000000 \
--num-threads=100 --max-time=60 \
--oltp-test-mode=nontrx --oltp-nontrx-mode=delete \
--max-requests=0 --percentile=95 run

结果:

OLTP test statistics:
    queries performed:
        read:                            0
        write:                           8062
        other:                           0
        total:                           8062
    transactions:                        8062   (119.45 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 8062   (119.45 per sec.)
    other operations:                    0      (0.00 per sec.)

Test execution summary:
    total time:                          67.4955s
    total number of events:              8062
    total time taken by event execution: 6290.0099
    per-request statistics:
         min:                                 33.34ms
         avg:                                780.20ms
         max:                              16901.57ms
         approx.  95 percentile:            3838.98ms

Threads fairness:
    events (avg/stddev):           80.6200/12.56
    execution time (avg/stddev):   62.9001/2.30

总结

操作类型	性能(QPS)
select	70801/s
insert	817/s
update	363/s
update_nokey	464/s
delete	119/s

macOS点击链接Chrome打开空白新窗口解决方法

2018-02-25T17:06:04+08:00

最近一个多月了吧, 从微信或者其他地方点击链接从 Chrome 打开(默认 Chrome 浏览器)时 Chrome 总是只打开一个新的空白窗口, 对源地址完全不感知. 把地址复制下来放在地址栏里可以正常打开.

解决方案非常简单, 找到 Settings->Advanced->System->Use hardware acceleration when available,(我用的是英文系统, 懒得找中文对应的翻译了). 相应的项目右边会有一个开关, 切换一下开关, 左边会有一个 RELAUNCH 按钮, 点击后 Chrome 会重启, 问题就解决了. 如果你还想开启/关闭硬件加速, 重新执行上述操作即可.