今天听了一个所谓的架构师的言论,颠覆了我的三观

2016-10-14 20:09:49 +08:00
 sunmonster

我是做 php 开发的,同时也会做一些运维,前端,数据库方面的工作,对这些也算有些基本的了解。今天跟那个架构师讨论了一些关于架构的一些问题,他说的话跟我自己所总结出来的完全相反,而且我也不是很认同他,主要有以下几点:

  1. 关于基本的 lemp 架构优化,我说 nginx , PHP 已经很快了,对于一个应用,它在发展的过程中首先出现的瓶颈是 DB ,所以要做读写分离。他说我是错的, php 的并发量是很低的,他说他做过测试, Laravel 只输出 hello world 的并发量才每秒 86 ,我不信,他说很多人都不信,但是我们做过测试,你有做过测试吗?我确实没做过,但是以我的经验来说不会这么底,他说 CI 也就 300 的并发量,所以做高并发的网站 laravel 框架是不行的。

  2. 因为他们用的服务器内存是 16G ,我问他你们 fpm 进程开了多少?他说不知道,我说 16G 大内存 fpm 坑定要设置成静态的,按照 50 ~ 100M 分配一个 fpm 进程,预留一些系统内存开销,很容易估算出大致进程数。他说他们是设置成动态的,进程数是一直在变的,所以不知道。

很多时候我想发表一些想法,他马上打断我说这是不行的,我说我还没说想怎样呢,他说你不就是想这样这样吗?

最后我向他要测试报告,他说这是公司内部信息,不方便提供,我也不好说啥。

8822 次点击
所在节点    问与答
42 条回复
myoula
2016-10-15 08:24:28 +08:00
这样也敢称自己为架构师?系统、网络,应用都不做调优就下结论。
sherlocktheplant
2016-10-15 09:08:58 +08:00
他知道 86 并发意味着多少 pv 吗?
lan894734188
2016-10-15 09:49:15 +08:00
用 hhvm 打他的脸
rrfeng
2016-10-15 10:18:59 +08:00
我只想吐槽题目:这特么也是三观
likezun
2016-10-15 10:25:24 +08:00
我虽然不是太懂,但我也知道: 吞吐量 和 并发(直接影响吞吐量) 是两回事!!!
那货说的 86 和 300 应试指的是 吞吐量, 然而却没有说测试的并发用户是多少,所以完全没有意义!!!
还有并发受程序,服务器硬件, web 服务,磁盘 io 等因素影响,不能单单让语言背锅!

另外并发量需求设计也是根据实际情况不同而不同,例如:

(从网上贴来)某网站存在注册用户数为 10W 人,但同时在线最多 1W 人,但这 1W 个人,可能只有 500 人会浏览帖子, 500 人会进行发帖,只有这 1000 个人对服务器才有交易,那我们计算并发量的时候,就可以以 1000 为标准(如果设计缓存则可以更低)!

如果吞吐量低的话,这个时候应该为了这个并发量而去优化吞吐量。

个人理解,请斧正。
qwer1234asdf
2016-10-15 10:57:33 +08:00
返回一条 hello world 跟渲染一个模板的开销相比,不是一个数量级的
qwer1234asdf
2016-10-15 10:58:10 +08:00
顺带说了,我工作电脑内存都 16G 了……你这还是 server 。。。
cevincheung
2016-10-15 10:59:45 +08:00
laravel 的性能的确不敢恭维。


但是拿一个前端语言说事,这就不地道了。他们家是就一台家用 PC 当服务器的么?
mrytsr
2016-10-15 13:59:13 +08:00
opcache 开了没
Rabbit52
2016-10-15 14:03:34 +08:00
laravel 的性能确实很低。
Rabbit52
2016-10-15 14:04:19 +08:00
不过这是 fpm 的锅,用 php-pm 会屌很多
pubby
2016-10-15 14:34:32 +08:00
单台 300 并发反正我是不信的

php 这种模式并发几十已经很多了,因为每一个并发请求都需要一个 php 进程服务,
这时候系统 load 会很高,其实整体性能会很差。

所以进程开太多其实是让系统死的时候更彻底。
Akasha
2016-10-15 15:06:11 +08:00
架构师这个词已经被玩坏了
wdlth
2016-10-15 18:27:40 +08:00
先把用户拉来再说吧,连个影都没有,就开始谈什么并发负载……
cjyang1128
2016-10-15 19:20:16 +08:00
web 服务核心是需要开发快,如果真的要高并发可以上 swoole 这些。理论上能通过加机器解决的问题都不是问题。
tabris17
2016-10-15 19:28:25 +08:00
第一条大致正确, laravvel 确实性能很差,又一个 zf 而已,性能比 Symfony 还差
likezun
2016-10-15 20:38:11 +08:00
@tabris17
说 laravvel , zf , Symfony 性能很差,真是错了~
它们都是高效的开发框架,开始的时候就集成了项目以后会有的功能和扩展(把你后面要做的高效而完美的实现了)。
说到开发效率,可以甩 tp, ci 几条街! 不过你得会玩才行, 而不是简单看一下,搞了个 hello world ,对比了一下时间就说它太慢,性能差, 是并没有理解框架的精髓~

另外,引用 symfonychina 的一句话, Symfony 是 php 的救赎,一个史无前例的伟大 php 框架
tabris17
2016-10-15 20:54:19 +08:00
@likezun 你说的开发效率,我说的是执行性能,鸡同鸭讲。

你要讲开发效率,我有更好的解决方案,何必被 PHP 拖累
likezun
2016-10-15 22:57:59 +08:00
@tabris17
执行性能(应该指单位时间内所做的事)的话, laravel , zf , Symfony 也是高性能的。
如果说拿输出 hello world 来做衡量标准的话,我表示程序什么都不干时是执行性能最高的。
还有就 web 开发效率来说, PHP 应该是最高效率的解决方案了
jin0927
2017-06-30 09:17:37 +08:00
你是 PHP 啊?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/312874

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX