服务器做了两个优化 CPU 使用率减低 40%

:+1:希望多发一些这样的文章哦 嘿嘿，非常不错，谢谢老大

厉害

:joy: :joy: :joy: :joy: :joy:

学习了

好，服务器就是你弄爆的，开那么多页面 :smirk:

我也开了好几个页面查资料

的确感觉比之前流畅了

mark

自从进了社区再也出不去了，全是干货。

是一个解决办法的思路，但是感觉还有更好的思路

希望有一套教程专门讲这种的

获取未读消息这个，要是前端有一个统一的锁就好了~

这个很稳

这种问题在测试阶段不能用ab提前发现吗？

@DianWang ab的时候你会发现 c10的时候一般双核服务器的负载就满了。。。

用户在增长，服务器需要自动预警。我们游戏服务器解决方案是：守护进程分析日志，来达到实时预警（当然主要是分析用户的短期异常输入），当然服务器运行状态预警其实也很方便做（一般都是运维来解决，研发不用动手） :stuck_out_tongue_closed_eyes:。

这是一台4核心的机器吗？我看第一张top图负载一直在5。
我在4核的云主机上压测laravel空框架，关闭session中间件，开启opcache。在c100的时候负载就18了，太吓人了。
负载4的时候cpu应该全都是100%满负荷运行。
站长有试过c多少的时候负载到4吗？

我最愚蠢的 bug：在 php 一个进程内，往数据库插入一条记录后随即根据 id 读取该记录发现返回为空。当初排查起来又是捕获请求，又是各种日志查看，结果最后找到原因后真的是想把自己打一顿?

:joy: 阅读量这类数据 不是一般都直接进radis吗

消息提醒这个为什么不用长连接嘞

@风中的白鸽 就是为了保持程序架构简单，部署省事，并且这个场景中实时性要求不强。

@canyuexiang 好久以前开发的，为了省事直接更新数据库

4核才并发100吗，

社区的notification是通过发送ajax来获取的。为什么不用workerman或者swoolen从服务端推送呀。

现在的查看数还是实时更新的啊，刷新一下就能开到变化

@joylee109 Keep it simple and stupid

站长何不开个踩坑板块，大家都来发这类的文章。

@Kevinvinvin 应该是查询数据库的值和 redis 当天值求和

@chaofei 我才也是:laughing:

@chaofei
@Kevinvinvin 不碰数据库哈，直接更新 Redis 里的，因为是内存存储，性能要好太多了。每天凌晨再同步 Redis 到数据库里，因为要保持数据一致性。

多发些 实用的

学到了，hhh

很实用啊，刚好项目也存在这样的问题

我想起之前我们那个程序并发上万时，做了很多优化包括你这些，100 台顶配服务器都扛不住的恐惧。。。

@chongyi 找个时间分享下哈

@Summer 好啊 :smile:

经常犯的错误，每次写SQL关联查询的时候，条件没传，也硬要关联查询一次，而不写判断条件。

我们做股票行情的更是，没上长连接之前，每5秒定时请求把服务器刷爆😂

哈哈，当初我做一个项目的时候辛亏讨论的人数较多，以上几点都说到了。

@Summer 大佬，特想知道本文中的【定位】这一步是怎么做的，论坛有教程吗？

@Summer 大佬，特想知道本文中的【定位】这一步是怎么做的，论坛有教程吗？

支持大佬，支持你

想知道是怎么定位到这两个问题的

@chongyi 那种就只能上 swoole golang node.js 这些，异步非阻塞 ，常驻内存，数据库连接池。

@依剑听雨 改用 Rust 了

1. JS 端使用 localStorage 在请求成功后记录 notification_requested_at 的值为 Date.now()；
   其实在请求前就更新这个值更好？

// 定时请求 message 方法
function message()
{
    if (没到时间) {
        // 把 localStorage 的值显示到页面
        return false;
    }
    // 更新当前 localStorage 的请求时间
    // ajax 请求
}

如果是先ajax请求，如果需要请求消息总数的那个页面稍慢一点，其他页面还是可以趁机去请求接口。

@侧面 有更好的办法可以分享出来~

@狼骑 同求！

经常做开发这些都容易遇到呢。

@侧面 不要感觉，举出栗子来

哈哈，按照这个配置又可以好好的装逼了。

我遇到的排查很久的bug，但是并不愚蠢，因为项目需求用了rabbitmq,用workerman做的,因为有和其他公司的rabbitmq服务建立长连接，为了避免连接断掉，执行了定时检查连接状态进行重连，但是重点在下面，大家看代码

   public static function getInsChannel(AMQPStreamConnection $rabconn)
    {
        if (empty(self::$channel)) {
            self::$channel = $rabconn->channel();
        }
        return self::$channel;
    }

这样处理在连接断掉时，就会出现问题，获取到的channel是旧连接拿到的channel，而那个连接实际已经断掉了，最后我是将这块代码抽出来，在检测到断掉且执行重连前将其销毁，最后问题解决。

@ikin 我们也差不多行业，不过这一块我是使用websocket+mongodb

学习了

献上我的膝盖，请收好~

最蠢的应该是死循环吧，然后服务器远程不了，只能重启。

哈哈 同习惯开几十个页面

哈哈哈，学到了