V2EX › keakon 的所有回复 › 第 4 页 / 共 59 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 59

❮

❯

2025 年 4 月 18 日

回复了 keakon 创建的主题 › 分享创造 › AI 帮我重新上架了 Chrome 插件： Copy Unlock

@1044523901 理论上绝大多数都支持，遇到有问题的网站可以在 github 提 issue

2025 年 4 月 18 日

回复了 suke119 创建的主题 › 程序员 › 企业级部署实操： SGLang 多节点集群部署 Qwen 系列大模型

@suke119 7B 都加载不了的显卡，其实不推荐玩大模型。另外，单机多卡也比多机快很多倍。

2025 年 4 月 18 日

回复了 suke119 创建的主题 › 程序员 › 企业级部署实操： SGLang 多节点集群部署 Qwen 系列大模型

如果单卡能部署的话，不要用 tp ，每个 GPU 开一个实例，前面用 nginx 之类的负载均衡，速度至少快几倍。

2025 年 4 月 17 日

回复了 keakon 创建的主题 › 分享创造 › AI 帮我重新上架了 Chrome 插件： Copy Unlock

@Pipecraft 我也不知道，当时 Google 对于隐私审查还不严，也许可以通过插件收集用户数据来盈利吧。
另外，有些人愿意买一些项目充门面，简历里挂个 xxx 开发者也加分嘛。

2025 年 4 月 17 日

回复了 chobits336 创建的主题 › 成都 › 成都节假日和周末可以约女生去哪里玩

妹子怕晒的话，还是室内比较好。博物馆、艺术展之类的，大部分都是免费。

2025 年 4 月 17 日

回复了 keakon 创建的主题 › 分享创造 › AI 帮我重新上架了 Chrome 插件： Copy Unlock

@yamedie 我试了下不支持起点。它在原理上就是解决不了使用 addEventListener 绑定事件的。并且没法记住用户的设置，每次打开这些网站都得手动点收藏夹。

2025 年 4 月 17 日

回复了 keakon 创建的主题 › 分享创造 › AI 帮我重新上架了 Chrome 插件： Copy Unlock

@kebamt 瞄了一下它的源码，原理是一样的，但是它的实现较复杂。
它通过消息机制在 backgroud 和 content scripts 之间进行通信，来确定是否对当前网站启用。但其实二者都可以直接访问 chrome.storage ，不需要引入消息通信来增加复杂度，并且这样也增加了延迟。
其次，它用的是 chrome.storage.local ，我用的是 chrome.storage.sync ，因此我可以在多设备间同步配置。
兼容性上，它绑定的是 HTML 根元素，我绑定的是 document 元素，理论上它可能存在更多漏网之鱼。（也许绑 window 更好）。

2025 年 4 月 16 日

回复了 LOGOSJ 创建的主题 › macOS › 老话题 MacOS 浏览器有什么推荐吗

Chrome 内存占用小于 Safari ，但是后者更省电。

2025 年 3 月 27 日

回复了 mxdyeah 创建的主题 › 程序员 › 在小内存服务器上，高效处理 30 万次/天 API 请求的数据库与缓存优化方案？

@mxdyeah 只有写才需要加锁啊，一天才几次

2025 年 3 月 19 日

回复了 daimaosix 创建的主题 › 程序员 › 请教消息队列的选择

@daimaosix 假设你有 1000 个 topics ，5000 个客户端。
原方案是某个 topic 收到消息，只会通知 5 个客户端来获取消息。
你的方案会导致 5000 个客户端来获取消息，然后大部分丢弃掉。
性能差异可想而知。

此外，RabbitMQ 默认是不允许同一条消息被多个消费者并发消费的，需要使用 Fanout Exchange 。此时每个消费者都是一个单独的队列，即变成 5000 条队列，发布消息的开销会增大 5000 倍。

2025 年 3 月 19 日

回复了 daimaosix 创建的主题 › 程序员 › 请教消息队列的选择

RabbitMQ 在低负载（< 30 MB/s ）下延迟更低，资源开销、易用性和稳定性都更好。但是如果 topics 过多，例如上千，就会显著影响性能。当然你也可以多部署几个 RabbitMQ ，将不同客户打散到不同的实例，让每个实例的 topics 减少。
Kafka 的内存开销很大（毕竟 Java ），稳定性不够好，但是 topics 增长基本不影响性能。

2025 年 3 月 17 日

回复了 mxdyeah 创建的主题 › 程序员 › 在小内存服务器上，高效处理 30 万次/天 API 请求的数据库与缓存优化方案？

用 SQLite 吧，我的笔记本上一秒 40 万次随机查询，比 Redis 还快。

2025 年 3 月 14 日

回复了 bronyakaka 创建的主题 › 程序员 › web 框架性能排名 techempower 发布 2025 最新结果

实际场景数据库才是瓶颈，Multiple queries 排第一的是个 js 框架

2025 年 3 月 7 日

回复了 sampeng 创建的主题 › 程序员 › 无聊算了一下 cursor 的成本

我测试是 cursor 的一个问题最多可以调用 25 次 claude ，只计算一次。

cline / roo code 每个问题大概花费 $0.3 ，效果略好于 cursor ，但是 $16 只够问 50 多次。

2025 年 2 月 25 日

回复了 lyxxxh2 创建的主题 › 程序员 › cursor 使用感觉

@buynonsense 自动补全、光标预测、代码生成和 agent 模式都是 cursor 更好