用webman做了一个应用，发布后控制台的一些问题。
此贴自动阵亡
先感谢社区各位朋友热心的帮助，上个帖子关于消费券的问题给了我很大的启发。
上一个帖子：https://www.workerman.net/q/8581
目前我在小范围用webman做应用，观察，等都成熟了（我自己技术使用）再切换，就和大神（@nitron）说的一样，线上项目要谨慎，还是先从硬件和流程改进吧。
今天做了一个小的程序，刚发布，刚才看控制台的status ，如下图
我这个是默认的启动，我看processes是17，这个是不是和cpu的核数有关系那，我现在是8核的，因为有两个worker，所以是8*2=16？，就是说一个monitor和16个webman进程。
问题有点小白，见谅哈，哈哈哈哈哈哈哈~~~~
1015 3 3
3个回答
相似问题
年代过于久远，无法发表回答
https://www.workerman.net/doc/workerman/debug/status.html
是的，webman 里面默认是开启 c 数量二倍的数量。如果是高i/o的你可以手动调的更高，如果是高计算的，也可以适当调低一点。
是的，之前没有升级编写过，今天上线个小项目，还是能学到不少的，不过我也不知道我的是高io还是高计算的，人不多，估计默认的就能应付了。
现在观察一切安好。
不够可能程序太小了，上线1个小时了，才200会员，估计看不出优势还。
其实就是一个请求中，php执行占用的时间和与其他非php交互的时间哪个占用时间多。高i/o的调高worker数量是为了不要让webman的worker都在等待 db/redis/或者远程调用的结果。这样cpu利用率比较低。时间都花在等待上了，可以适当调高worker数量。如果接口中的判断，或者计算相关逻辑比较多，占接口响应时间比较大的，但是查询很快的话，就要适当降低worker数量（不要小于cpu核心数，小于的话，就会有核不被利用了），目的是为了减少系统在多个worker上的切换。减少并发时任务切换的时间占比，让cpu尽可能的用在真正的逻辑上。 具体还是要看场景，不过一般接口的话，默认为cpu的二倍没什么问题
@缝合 嗯，了解了，多谢。
回答的很精辟呀，收藏
不是什么大神，太抬举我了，我的建议能帮到你我也很高兴。
说的其实不是什么比较有技术含量的提议，主要还是个人的经历
很多年前第一次升职，年轻啊，新官上任三把火，想马上干出点成绩。正好当时有个新的业务，想着正好啊，跟各路大神请教之后，决定换了个技术栈，却完全没有考虑当时团队的状况和其他一些技术之外的问题。
当然之后的结果估计大家都能猜到，项目延期，上线后问题不断，团队的气氛也差了不少，客户也有不少怨言，上线磕磕碰碰快两个月才完全稳定，真感谢当时的领导一直护着我，不然我估计要收拾东西滚蛋了[/叹气]。
大家的意见你只能做参考，因为他人只是说而不用实际执行，他们初心是好的，都希望能帮你解决问题，但最终要落实还是你。你那个提问里，群友们的热心回复，我感觉看到了当年的自己，怕你头脑一热就上了，就多提了一嘴。
很多问题，实际上不是什么技术问题，而是如何权衡的问题，总结起来就4个字“量力而为”。未来如果换了Webman，也希望你能在这里多分享。
嗯嗯是的呀，我现在也是那个消费券项目没有替换技术栈，目前一些小的项目用了webman（本月用了2个），会都发布出来并分享一些小的体会和经验。
我这边客户到时支持替换，不过都知道，除了事情肯定还是乙方的责任，哈哈。
是要慎重。