V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  zuiye111  ›  全部回复第 1 页 / 共 2 页
回复总数  27
1  2  
74 天前
回复了 dwlovelife 创建的主题 程序员 线上 RPC 调用超时问题请教
是偶现还是常态?
偶现的话,看是否网络抖动导致 B 的回包超时; A 节点负载是否过高;
常态的话,分析 A 模块逻辑,除了简单 rpc 调用,是否还做了其他耗时逻辑,导致你统计本身就不对?框架本身是否有自动换机重试机制?例如 A 调用 B1 ,超时 1s ,换机调用 B2 ,又超时 1s
再者,是否有链路追踪,traceid 之类,分析超时前后上下文日志
坐标 wxg ,整个 wx 全是 c++
170 天前
回复了 isno 创建的主题 程序员 ¥ 2890 人民币,买了 5 台腾讯轻量云服务器
手里有大量优惠券,出售腾讯轻量云服务器,1c1g ,每月 25 ,250/年,其他配置也可以出
我这里有很多腾讯云代金券,都不知道怎么花。。。
正好最近在做一个海报中心项目,当时做方案时也是在考虑前端生成还是后端生成,所以这个问题我也回答下
我们的产品形态是小程序
1 、前端生成
优点:对后台友好,由于我们项目后台都是 C++,要找一个画图的库还是比较麻烦,前端合成可以降低后端开发压力,其次可以充分利用客户端计算性能,灵活
缺点:就像上面说的,需要考虑不同机型适配,字体问题,其次,要考虑前端生成的海报如何传给后台?传二进制流?还是合成后上传 CDN 再给后台?再者,由于我们还支持用户上传图片,小程序里可能支持性不够好
2 、后台合成
优点:可控性,可靠性,统一性更好
缺点:开发成本较高
最终和前端同事讨论比较,还是选择后台单独写个合成图片的服务,前端使用 svg 渲染海报模板,用户编辑后,再把 svg 转 json 传给后台,后台合成图片并上传 cdn,返回给前端 cdn 地址,最终,经过优化,合成的速度基本控制在 1~2s 。
目前我们海报中心小程序已经在灰度中,支持特殊字体,好友码,上传图片等功能,如下图
https://wx.gtimg.com/resource/feuploader/202102/b540d53198dd75d1b2c2d9cad6453014_1080x2337.jpg
2020-11-06 10:01:55 +08:00
回复了 lambdafate 创建的主题 程序员 有没有简洁的博客主题推荐一下
@AmosAlbert 看看这个,除了黑白,无其他色彩,个人一直用 https://xujimmy.com/
本人本科通信,研究生光学,15 年毕业,第一份工作 python+php 两年,后来 java 1.5 年,现在 c++半年,都是大厂,都是入职现转的,LZ 体会下
2020-02-23 14:47:54 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
感谢上述各位大佬解答,很有参考意义
2020-02-22 16:31:44 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@goodboy95 不用想那么复杂哈,这里就是写 sql 时为了拼接,仅此而已
2020-02-22 16:28:52 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
慢的问题大概清楚了,但还有个问题不太清楚
同一条 sql,explain 时,为何有时用了 create_time 索引,有时又用 mchcode 索引?
2020-02-22 16:21:24 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@GGGG430 嗯,这个是线上生产哦,不敢随便乱搞。。。
force index 可以强制让 mysql 使用哪个索引,单纯测试可以用,但不是这里的解放办法
2020-02-22 16:16:57 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@Sasasu 使用 create_time 时,是 1311 哦
最好情况下扫 1 行,正好 create_time 最大的那行,满足 filter 条件。最坏的情况,扫到 create_time 最小的那行,还是不满足 filter 条件,是这样吗?
然后 rows 的值,只有参考意义,但实际扫了多少行,是不知道的,是这样吗?
2020-02-22 16:05:20 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@GGGG430 嗯,这里我也有这个疑惑,用 mchcode 索引或者 create_time 索引,rows 都差不多,但查询时间相差巨大,所以解读 explain 时,关键是看哪个字段? ref ? rows ?
2020-02-22 15:59:07 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@GGGG430 这是用 mchcode 时的 explain
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+
type | possible_keys | key | key_len | ref | rows | filtered | Extra |
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+
ref | mchcode | mchcode | 63 | const | 1312 | 0.27 | Using index condition; Using where; Using filesort |
------+---------------+---------+---------+-------+------+----------+----------------------------------------------------+
2020-02-22 15:57:35 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@Sasasu 哦好像明白了,因为有 limit 1,所以过滤到一个就结束,假如没有 limit 1,索引又是 create_time,估计会扫全表,或者根本就没有满足 filter 条件的数据,也会扫全表。是这个道理吗?
2020-02-22 15:54:29 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@GGGG430 你说的有点问题,explain 的这个 filtered 字段,是百分比。。。当用 mchcode 索引时,这列是 0.27
2020-02-22 15:51:02 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@Sasasu 按你的解释,那我这 sql,由于有 filter,如果 mysql 使用了 create_time 索引,那必定会扫全表了?因为必须得一条一条的按 filter 过滤
2020-02-22 15:36:28 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@lasuar 为啥要把排序去掉再 explain? 这样 explain 出来的结果,对原 sql 有指导意义吗
2020-02-22 15:33:22 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@GGGG430 嗯,感谢指导,这些道理我也明白,尽量不要把运算搞到 sql 中,但这里的问题不是因为这个运算引起的,因为换使用 mchcode 索引时,查询仍然很快,使用 create_time 就很慢
2020-02-22 15:28:56 +08:00
回复了 zuiye111 创建的主题 MySQL 请教一条 mysql 慢查询问题
@Sasasu 如阁下所说,只要是 order by xxx 形式,即使 xxx 上建了索引,仍然有可能会扫全表?那么,什么情况会是你说的最好复杂的 1,什么情况下最坏扫全表?
其次,同样的 sql,explain 时,为何有时索引用 create_time,有时又用 mchcode? (大部分情况确实用的 mchcode 索引)我知道这个是优化器的一个策略,但为何会算出不同的策略呢?
1  2  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2241 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 46ms · UTC 14:06 · PVG 22:06 · LAX 07:06 · JFK 10:06
Developed with CodeLauncher
♥ Do have faith in what you're doing.