单核 -512M内存-2000并发正常使用

自从自己创业以后就很少写博客了，也许是太忙了。也许是无法静下心好好研究一个东西。今天把我们做的后台做了下压力测试。结果还可以，尤其是对于我这种从java转过来土人。

4年前看到一篇抨击java的文章 《名词王国之死》，当时很不屑，现在看来在很多场景，尤其是能真正给用户节省资源的地方，java真的差了不少。之前使用tomcat，一台4g内存的服务器，死活上不了1000并发，tomcat这东西的对硬件的利用率太低了。我们来看看ngx+nodejs

---

测试环境

机器型号：vmware 虚拟机，分配最大内存1G,分配cpu核数1核，单线程。（原始机器为办公电脑：i5-4690，4g内存，500G硬盘）

系统控制： pm2 设置： 内存< 256M ,production 模式。

测试工具： jmeter - 2.1.3

系统软件： nginx , yliyun-server, mysql , reids

压测接口： 文件列表[100个文件] ，用户列表[100用户]，小文件上传（<500K）

测试步骤

循环次数：（10次）

线程数依次： 100， 500 ，1000， 1500， 2000， 2500， 3000，

测试结果展示【仅展示文件列表接口】

• 100 线程（类似100并发）

线程数设置为100，启动时间为3秒，单个线程循环10次，出错继续（后续都是如此配置）

我们可以看到100并发，当然是毫无压力，继续。

• 500线程

ok, error% 这一栏为0,用户列表是另外一个请求，这里也跟着跑了10次，无视即可。

• 1000线程，过个小关

我们看到 error 一栏表明是1000是毫无压力的。这里将接口返回的数据量增加到了1215.3KB,列表中显示的数据为30列，算是更加符合我们正常习惯性使用。

还可以看到应用所占的内存从开始的(500线程)的189M上升到197M，有小幅度增加。平均数据返回为4s，这是能接受的极限了。

因此可以得出结论，这种配置（单核，512M内存）的机器，并发在1000左右是比较理想的。

但是我们压力测试不是正常使用，必须继续，压到出错，或者拥有崩溃为止。

• 1500线程

看看error,无错通过。 看是平均延迟到了7.2s，内存使用上升到227M,这里我在pm2 脚本设置了最大内存为256M，"max_memory_restart": "256M",,为了更要的压内存，实际情况中不推荐设置。

使用 top指令 看到 最耗内存的就是应用和msyql 数据库了，我们没有数据库列表缓存起来，缓存起来测试就显得没有意义了，但是实际使用中是需要开启缓存的。

2000线程

这里我把线程创建时间修改为5s，免得自己的机器被卡死。没有错误,内存快满了，平均延迟到达10s，对于用户使用来说是要被吐槽的，没关系，傻瓜才这么用。

看看偏离，2888，看上去还不错。

到此目的已经达到，经过我们改造后的一粒云的后台（v1.1）处理能力相当优秀，当然这受益于nginx 与nodejs的异步机制。如果你有这方面的难题可以和我们交流。

我们的产品官网是 www.yliyun.com，欢迎大家试用，提供邀请码：[wymf008]。产品是免费的。客服妹子西瓜qq：2941390949。

• 2500线程 我们还应该继续

出错了，5个请求出错，日志显示都是超时，我们可以看到max这一栏超过60s了，ngx配置keeplive 时间为60s。内存也接近250m。

• 再试试3000线程

感觉上一把的0.02%的错误还有点小，再压压。

结果差不多，都是超时导致。如果还要提升的并发的话必须要加大内存才行了。

cpu 也一样，我一路监控下来都是在82%-95%，但是nodejs 必须再多开一个进程。

好了，技术是没有优劣没有尽头的，合适自己的才是最好。