@sunjourney 论 GPG 公钥签名的重要性

如果我攻破某个仓库，在里面放了我伪造的公钥，但我却没办法伪造发布者真正公钥上的各种交叉签名
可以粗暴（并且不严谨）地解释为：没有和他人交叉签名的 GPG 公钥，其可信度和自签名的 SSL 证书一样，随缘

@AstroProfundis 又看了一遍，我也不确定我是不是看懂了你第一个问题... “只能靠发布公钥指纹在站点上可以防止这点” 网站也可以被黑啊，按这种极端推论的话...

另外，理论上只要公钥发布出来的第一时间是发布者本人的那一个，然后别人存下了这个公钥，后面发现签名的公钥变成了另一个而发布者本人没有公布过“以上一个公钥签名的表示更换为下一个公钥的申明”，就可以认为有问题了

至于怎么保证第一个公钥确实是发布者本人持有， WoT 就是专门解决这个问题的

1. 实现你说的那种情况，前提是网页或其他某个地方公布的公钥、和签名提交用的公钥，都被攻击者替换成自己的，概率比单点爆破低很多；当然不能说不存在

2. passphrase 是在有人拿到了你的私钥文件的情况下提供的最后一层遮羞布

在把源安装调整成和编译安装一样的 PHP 设置（进程数和 CPU 核数相同）之后，结果变成了源安装比编译安装略好

PHP 配置：
pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.process_idle_timeout = 10s
pm.max_requests = 2048
rlimit_files = 51200
rlimit_core = 0

结果：
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.167 (be patient)


Server Software: nginx/1.8.1
Server Hostname: x.x.x.167
Server Port: 80

Document Path: /?paged=2
Document Length: 48526 bytes

Concurrency Level: 50
Time taken for tests: 6568.194 seconds
Complete requests: 25000
Failed requests: 0
Total transferred: 1218625000 bytes
HTML transferred: 1213150000 bytes
Requests per second: 3.81 [#/sec] (mean)
Time per request: 13136.388 [ms] (mean)
Time per request: 262.728 [ms] (mean, across all concurrent requests)
Transfer rate: 181.19 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 1030 13123 514.0 13130 17304
Waiting: 158 12224 499.5 12236 15666
Total: 1033 13123 514.0 13130 17304

Percentage of the requests served within a certain time (ms)
50% 13130
66% 13209
75% 13258
80% 13289
90% 13381
95% 13508
98% 14403
99% 15127
100% 17304 (longest request)

所以目前的结论是： php-fpm 的 max_children 要设置成和 CPU 核心数（逻辑核心 /进程数）相同

接下来使用楼主的 oneinstack 编译安装，尽量选择了和源安装一样版本的组件
PHP 5.4.45 / MySQL 5.6.29 / nginx 1.9.14
使用自带脚本新建虚拟主机安装 WordPress, 没有做任何性能相关的配置调整

其 PHP 配置为：
pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 2048
pm.process_idle_timeout = 10s

结果：
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.169 (be patient)


Server Software: nginx
Server Hostname: x.x.x.169
Server Port: 80

Document Path: /?paged=2
Document Length: 48542 bytes

Concurrency Level: 50
Time taken for tests: 6709.842 seconds
Complete requests: 25000
Failed requests: 0
Total transferred: 1218475000 bytes
HTML transferred: 1213550000 bytes
Requests per second: 3.73 [#/sec] (mean)
Time per request: 13419.683 [ms] (mean)
Time per request: 268.394 [ms] (mean, across all concurrent requests)
Transfer rate: 177.34 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 2
Processing: 1025 13407 1253.2 12827 19857
Waiting: 1024 13407 1253.1 12827 19857
Total: 1027 13407 1253.2 12827 19857

Percentage of the requests served within a certain time (ms)
50% 12827
66% 13784
75% 14249
80% 14535
90% 15274
95% 15782
98% 16355
99% 16821
100% 19857 (longest request)

结果略好于源安装，总时间较短但单个请求消耗的时间分布更散一些，这个结果比较符合我心目中自己编译的效果（没有明显性能优势但应当和集中打包的二进制表现相当或者略好） @vibbow @yesono

以及这次的两个结果明显比两年前的要好（物理机是同一台，而且我还专门找了老版本的 WordPress 来减少变量），说明程序本身的进步也不容忽视

为了排除进程切换的影响，我正在用和脚本配置一样的 php 在源安装的机器上跑第三遍

下午没事又搞了一遍，和 https://v2ex.com/t/87755 这里几乎完全一样方法
两台 OpenVZ 虚拟机 256MB RAM/256MB vSwap, 4 CPU, Debian Wheezy 64bit 更新到最新
装上 WordPress 3.7.1 英文版并导入主题测试用例
再从同母机的第三台虚机用 ab 抓第二页 ab -n 25000 -c 50 http://hostname/?paged=2

----
首先是源安装，用了 dotdeb 的默认源
PHP 5.4.45-1~dotdeb+7.1 / MySQL 5.6.29 / nginx 1.8.1
除了 nginx 加上了 PHP 支持以外，全部使用默认配置

其 PHP 配置为：
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

结果：
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking x.x.x.167 (be patient)


Server Software: nginx/1.8.1
Server Hostname: x.x.x.167
Server Port: 80

Document Path: /?paged=2
Document Length: 48526 bytes

Concurrency Level: 50
Time taken for tests: 7082.100 seconds
Complete requests: 25000
Failed requests: 0
Total transferred: 1218625000 bytes
HTML transferred: 1213150000 bytes
Requests per second: 3.53 [#/sec] (mean)
Time per request: 14164.201 [ms] (mean)
Time per request: 283.284 [ms] (mean, across all concurrent requests)
Transfer rate: 168.04 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 2
Processing: 1052 14149 1201.5 13998 19505
Waiting: 154 12951 1037.2 12671 17456
Total: 1054 14149 1201.5 13998 19505

Percentage of the requests served within a certain time (ms)
50% 13998
66% 14600
75% 14957
80% 15202
90% 15765
95% 16223
98% 16772
99% 17149
100% 19505 (longest request)

是 1999 年 5 月...

@yesono 是的，这个是最奇怪的地方，目前只能想到打包操作的整体编译环境会和直接编译不一样，这几天有空我会尽量试一下，但不一定_(:зゝ∠)_

@yesono 所以我就是想知道 {官方源打包,自己建源打包,自己直接编译} 这几样东西到底有什么区别，就目前观察到的情况是官方源和自己打包性能没有明显差距，直接编译会更差，但不知道为什么

@yesono 关键不是实际性能的绝对值，而是和编译安装和包安装的相对性能差距，我有空可以试试（最近不一定），以及我实在想不通编译的会比源里面的差是为什么...

如果谁有心能反复测试各种参数 /配置找到超过源安装的组合，也算造福大众了

https://v2ex.com/t/87755
我想知道有没有人有闲心再做一下这个测试
不是针对楼主，是真的好奇，因为我至今也认为上面帖子里的结果是不符合直觉的

@tabris17 嗯，这样的话有可能直接是运营商网络的问题，然后局域网内的 resolver 向上查询其实和你自己直接查遇到了一样的情况

10.21.168.202 这个内网 dns resolver 可能有问题，试试用公网的 public dns

@AstroProfundis 手抖脑抽没放链接... https://atr.me/

无耻骗流量， fork 过来稍微改过一点点，来源在页面左下

OEM 的 win7 直接升级就是正版 win10 了，根据官网的说明是永久有效的，之后再直接拿 win10 的盘重装也有效