两个方案都不跑数据库，数据库是另外独立的机器。两个方案并发大约分别能抗到多少？
This topic created in 2984 days ago, the information mentioned may be changed or developed.
 |
1
安装 object-cache , 逻辑上多使用 wp_cache_set , wp_cache_get 等函数处理，你会很爽。
|
1 |
2
后者，机器不像人类，1+1 通常都会大于 2。
|
 |
3
为什么感觉是前者？缓存走的内存。
|
 |
4
我们是后者，但是坑比较多，
|
 |
sagaxuSep 10, 2018 via Android
5
不如两台 4 核 8g
|
 |
6
@s609926202 考虑后者的话：LVS + (nginx +wordpress)*4 这样坑会多出在哪个环节？
|
 |
bellchuSep 10, 2018
7
后者：一台负载均衡，后面两台 WP 并排，再后面一台独立的 SQL 服务器。
|
 |
8
前者
如果是物理机， 后者的优势是 IO 性能和网卡吞吐量比前者强一点 但是， 后者这配置分明是 VPS 啊，IO 和网卡吞吐量都得受限母鸡， 再说你 8 核 16G 的机器去开个 4 台 2 核 4G 的 VPS 性能怎么也不可能比母鸡强吧 |
 |
ywgxSep 10, 2018
10
楼主别折腾了，你只需要一个 CDN 而已
|
 |
11
系统、系统级软件占用内存还是蛮高的，8H16G 这种量级的机器分多了反而划不来。总带宽不变情况下，还不如一台进行软负载均衡。
|
 |
12
前者更好。
集群方案损耗是很大的，就像团队人多以后的沟通成本。 而且环节越多问题越多，维护成本也高。 当然，如果你是考虑故障冗余，那后者好。 打个比方： 2 个优秀程序员，比 4 个半吊子程序员或者 8 个萌新，效率更高出活更快。 但如果考虑到程序员可能生病啊出车祸之类的，那就人多好了，可能无法按时完成，不过项目还能蹒跚前行 😀 |
 |
13
必然第二种好，一般单机故障可以对外不表现故障，云架构之所以单机性能低了那么多还这么就行，看中的就是服务整体可用性
|
|
opengpsSep 10, 2018 via Android
14
我甚至有些时候提倡 8 台 1 核 2G
|
 |
15
显然负载均衡的更好呀。
|
 |
17
Nginx + PHP-NODE * 4 顺便在 Nginx 加一层 Proxy Cache
|
 |
18
待过 2 家有关 PHP 高并发处理的公司，在 24 小时 20%时间单位内的百万级白发，建议前者，理由如下：
1.并发优先下，因为没到那个压力级别不能体现出差距，其实 2 者差距不会太远。 后者每台服务器白白占了 1G 多 swap 和系统内存， 前者只消耗一份内存，亲，完完全全给你多出来 15G 给你用 php-fpm 啊，考虑一个 php-fpm 占用 30M，差距就出来了。 2.前者调试部署上线方便点，后期再考虑 deployer 或 git 集成部署 3.前者方便横向扩展， 等单机并发量上来后，再做镜像 copy 扩容。因为集群后 16G 的性能远远是 N 台 4G 的多倍（经验） |
 |
qsbaqSep 10, 2018
19
显然是负载均衡更好~
|
 |
jimzhongSep 10, 2018
20
性能显然前者更好。故障冗余后者更好。
|
 |
batterSep 10, 2018
21
看访问量加缓存，加 cdn，单台应该足够了
|
 |
HFcbyqP0iVO5KM05Sep 10, 2018 via Android
22
负载均衡啥时候都能做，不如先用两台机器跑，看看性能极限。
当然如果是已经遇到了性能极限，现在考虑的事情是加配置还是加机器的话，建议是加机器。 |
 |
jmk92Sep 11, 2018
23
这个要看 LZ 对内存的需求，如果程序过多的依赖内存且没有缓存服务器的情况，优先前者。
否则还是后者的扩展性更高，可以实现随时的弹性伸缩，业务的变更，机器的重启变更等等，都可以无缝的实现，不单单是故障冗余，当然，配置也不能太低，像你这种情况，两台 4 核的就可以了 |
 |
lschoSep 11, 2018
24
和 23 楼观点一致，说简单点，如果程序没有太多依赖内存（比如某些内存缓存）。那么必然是第二种情况更好。单机架构永远没法和负载均衡相比。
|
 |
NitromethaneSep 21, 2018
25
两台，数据库必须做主从，防止丢数据。
|
 |
qshujunNov 13, 2018 via Android
27
从我们测试来看，前者性能更好，后者可靠性更好，如果是我，会用 2*4u8g。
如果有容器方案，会优先用容器。 |
Select Language