AstroProfundis

大法可以真×水冷

感谢已发送

http 代理不加密码不是找死吗，屏蔽完阿里云还有别的来，唯一出路是设置白名单...
或者设密码...

如果你想走他特别高兴，你才该纠结吧...

@aa45942 CDN 的根 NS 是看不到你的客户端 IP 的，只能看到你往上（可能 x 若干）级之后的递归 DNS 解析器地址，所以 ISP 的 DNS 很多时候效果最好，而公共 DNS 反而不一定；具体流程在 39 楼 @XiaoxiaoPu 贴的图里面

[quote]这些东西搜索一下就有，没什么理不理解的，关键是为什么要这么分配[/quote]
我没说我不知道 CDN 是什么鬼，我是觉得你的理解和这楼下面大部分人都不一样，说来说去不在一个频道上

按你说的先到某个中转域名再 302 到 CDN 节点，那这个中转域名要怎么部署？
-> 为了保证访问速度是不是自己也要上 CDN?
-> 那它是用 302 负载均衡呢还是用 DNS 负载均衡呢？
-> 用 302 的话是先有鸡还是先有蛋呢？
-> 用 DNS 的话干嘛还要加上这一层呢？

另外你真的觉得（从服务商角度看） 100 万次 HTTP 302 响应比 100 万次 A 记录响应更快？

楼主你能不能先讲讲你理解的 CDN 做负载均衡分配的流程？

@sunjourney 要我说的话，这个只是解决公钥分发方便的问题，安全性校验是交给 PGP/GPG 本身了，于是真正管用的唯一手段是保证自己的公钥在 WoT 网络中并有足够的交叉签名以显得可靠（伪造难度较高，但通过一些社工手段显然还是可以伪造）

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