显卡的叫， 大部分情况是；还有其它的情况是主板 or 电源

——
1.缩小后端生成图的场景，

————
2.解耦，用专门的语言+显卡 simd 等支持的加速。 这个虽然 B 站恶心，但是 B 站整的客户端 wasm 缩小服务器占用可以参考。 -------- 反正你这个应该是商务的应用吧？ 不过就看你的顾客骂不骂风扇起飞了
——————
3.部分情况可以尝试性试试 Java 平台的 simd ，gpu 的支持。 不过这些要么是 jdk22/graalvm 22 才支持，并且还是 preview ，或者是魔改的 jdk---比如 TornadoVM https://github.com/beehive-lab/TornadoVM

如果能缩小硬件占用，or 硬件加速，这明显就是现代网络会议。不需要高保真的语音存储备份的好东西。

那种便宜点的城市技术聚会，可以去去，这种属于广告会，没多少时间交流啥。

身体健康，有序计划也很重要，可以和现在在老家的同学联系，看看他/她们的生活是怎么样的。

@luozic https://github.com/valeriansaliou/sonic

可以走 elk 那一套，这一套有单机版本 并且可以后期切换。
单机版本的比如 sonic 。 已经可以支持 tb 级别了，等到后面超过 10tb 了，这种明显可以迁移了

可以找个学前端的后端 互相学习

1.定期项目总结，尤其是完成一个项目后，啥加功能造成了啥问题，导致啥发版本延误，bug 多啥的。这种必须给出确定的数据，否则产品经理锤子用。
2.估时间的时候把，根据之前经验，把要临时加的时间加上去

是练技术 还是练项目，还是为了面试？
1.练习项目去找些网上的半公益的项目做做，
2.练技术，分成刷 leetcode ，刷那种习题，刷比如 1brc 这种。
3.面试明显去看看最新的面经，了解一下大家面试面啥

真为了性能+追踪，那都是用 kakfa 等 mq 去异步写入，至于之后存在啥地方，看公司规划

基于 swagger 的 openapi 标准再搓呗，这个是现在的标准，都已经到 3.0 了 GitHub 上有协议

首先排查一下硬件：cpu 内存 硬盘问题。 之后就是排查缓存 系统是否中毒等问题

gcc 编译器下面才可用，使用的是 gcc 的一个 feature ？

可以放一个服务器，但是备份和后面的分散隔离的计划做好。
不要在数据库里面玩耦合。

@luozic 并且这也是为了方便改 cqrs ，读写分离等后期优化

看资源粒度和接口定义方式，不过为了日志清晰和安全，只用 get post 作为 http 请求，但是在 controller 那里根据操作转义

前面套了防火墙，让防火墙处理