@Gempty #23 优化了 maxThreads 从默认的 200 提到了 1000 但是之后没有什么爆款活动了，服务器压力一直不大，想通过理论知识想清楚这样到底能不能提升性能。因为 cpu 是 8 核 16 线程，那理论上无论在哪个瞬间，同时执行的线程数量都只有 16 个才对吧。提高线程数量，只是同时调度的线程数量变多了，那相应的每个线程的处理时间也变得更长，这样还会增加 cpu 切换线程的压力。我个人觉得逻辑应该是这样的。

还有一点就是不知道 fd 用不用调高上限，现在几乎一半的人回答用！另一半人回答不用！还有人说默认的 1024fd 效率是最好的，如果调高 fd 处理效率会降低。我也不知道哪些是对的。

果然还是应该自己掌握压测软件，多调多压……

@micean #20 没太明白 如果不换 cpu 那 cpu 的核心数和线程数是固定的啊 那假如我现在线程池的数量已经大于核心线程数量了 那再提高线程池的数量不应该是增加了同时调度线程的数量 相应的 每个线程执行的时间也变长了吗？ 因为有很多时间分配给其他线程了

@Gempty #21 早就已经调过啦 现在 3 分钟一次 full gc 我觉得还行

@lihongjie0209 #17 哈哈哈 不可能的 无论什么语言都是需要优化的 就算是前端 也需要针对客户端优化 毕竟资源是有限的 技术才是硬道理啊！

@DovaKeen #15 嗯 有道理 果然还是应该先压测什么的 掌握系统目前的各项性能指标

我觉得分布式系统本身就是为了解决高流量下的高并发问题的 小公司确实不适合上微服务 第一项目没到那个体量，第二 上了微服务之后有很多的问题需要解决，比如分布式事务什么的。有解决这些问题的时间，用单机架构可能已经写好上了第一版了，而且流量小的时候也不会崩，项目到了一定体量再考虑重构也不是不行。 不过用 springcloud 对开发来说可以提升技术，没什么不好的。

@micean 为啥啊？ 如果有更多的线程阻塞在等数据库 IO 那加线程不是更多线程等待数据库了吗？

@jicg 哈哈哈 弃坑还行

@DovaKeen #2 确实是应该有一个函数关系 只不过我想弄清楚每一步的原理，好能更准确的找出那个最优值

@AngryPanda #3 不太懂 我一直在中小公司呆着 我上网查查

@gabon
@qilishasha
@liuxey
#4，#5，#6 是 IO 密集型 现在基础知识缺失较多 不太好找瓶颈在哪里 公司也没有大牛支持 很烦

追 nm 个臭嗨

什么是菠菜？

同#8 非常好奇 加班做开源？

@WEAlex 非常感谢！可能就是差在这了！

@catteroLo #37 但是这种情况也是很普遍的 就想我当年下了战地 3 赫然发现不支持 32 位系统 只能老老实实装 64 位 时代在进步 技术不断的更新 肯定得舍弃一些老的东西的 不然就不会进步

@jasperjia 说的对 支持大佬的观点 现在很多苹果黑 tx 黑各种黑 只要自己不喜欢的东西就是无恶不作 罪该万死 凡事都要讲道理 游戏开发商不维护了跟苹果有毛关系？

@mashiro233 你这么说我就有点清晰了，不过还是觉得你说的这个优点，代价有点高，可能是我没接触过太大体量的项目，不过还是多谢大佬指教了！

@q397064399 @mashiro233 首先谢谢两位大佬解答，但是我还是有不懂的地方，就是负载均衡和分布式的区别，因为我身边的同事几乎很少会 spring cloud 的，而项目经理也说，并发问题可以通过负载均衡来解决，那么像 zookeeper，dubbo，eureka 这些分布式框架的意义何在？因为我刚从成都回来，成都那边确实很多公司都要 spring cloud，我估计深圳杭州那边可能会对 spring cloud 要求更高？如果说只有项目量级达到淘宝京东这种级别才用得上 spring cloud，那为何需求会这么大？另外负载均衡也是通过增加服务器就可以解决并发问题，但是 spring cloud 却会高出很多的人员成本，那到底 spring cloud 或者说 dubbo，zookeeper 这种分布式框架应该什么时候用？跟负载均衡比又有什么样的优势呢？

@q397064399 但是如果微服务的东西都可以用单体应用来解决的话 那为啥还要用微服务？多一个微服务不就要多一个 tomcat 这样弊大于利啊

@iwdmb 但是拆一个单元就是多启动一个 tomcat 啊 生产环境成本很高