对这个 API 优化的较好方案

先通过 profile 把瓶颈找到，你这说得好像？ 确定了才好动手优化

我有个笨办法，就是在后台代码不同位置打时间日志，记录当前时间，然后不断调整打日志代码位置，把最费时间的那一段代码找出来

@luozic 好的，我看下哈

@opengps =。= 也是办法哈

换个语言能快不少吧。。比如 go

如果图片不用马上展示的话，可以异步生成图片

本地文件能花 5 秒吗。。。

@donething IO 问题，go 也快不了多少吧……更何况是 5-8s，语言差异能快到哪里呢

感觉是获得那个微信的小程序码吧，模拟浏览器去下载它。

是类似制作带二维码的分享卡的功能么，一般做法是后台获取小程序码，保存在服务器，返回前端网络路径，然后前端 canvas 绘制渲染海报样式保存图片。后台一般不做图片处理的，简单的裁切缩放可以交给前端，还能转移服务器压力，我做的小程序都是这样，具体耗时看各个手机性能，但一般都是 2~3s，好点的手机整个过程 1s

要是给后台处理的话，同时又 100 个处理请求估计就 gg 了

@guiling 对，是这个工作。我们前端说 canvas 难画，说有适配性能问题不做。。只能我来做了。。现在就是这样，请求量一上来就没了。

这种需求必定用 canvas 做啊，犹豫什么
适配问题，如果前端不支持再出个 loader 交给后端，再说了现在还有不支持 canvas 的？？？

@luozic

从 profiler 看还是慢在网络请求和生成图片那了

Total time: 0.691589 s
File: upvote_func/upvote_func.py
Function: generate_upvote_share_image at line 90

Line # Hits Time Per Hit % Time Line Contents
==============================================================
90 @func_line_time
91 def generate_upvote_share_image(organizer_id):
92 1 1509.0 1509.0 0.2 user_info = get_user_info(int(organizer_id), ["user_avatar"])
93 1 1.0 1.0 0.0 if not user_info:
94 return
95 1 1.0 1.0 0.0 user_avatar_link = user_info.get("user_avatar")
96 1 0.0 0.0 0.0 if not user_avatar_link:
97 return
98 1 4.0 4.0 0.0 scene = UPVOTE_SHARE_IMAGE_SCENE.format(organizer_id)
99 1 0.0 0.0 0.0 mini_program_code_image_io = get_mini_program_code(
100 1 374455.0 374455.0 54.1 UPVOTE_SHARE_IMAGE_PATH, scene)
101 1 4.0 4.0 0.0 if not mini_program_code_image_io:
102 return
103 1 315615.0 315615.0 45.6 return generate_image(user_avatar_link, mini_program_code_image_io)

html2canvas 了解一下？

@Molita 前端不愿意自己画的话网上有一些开组件的，原生的或者框架的都有

那就和老板反映下吧。。转移到前端做

你这是是朋友圈分享图之类的吧。
生成小程序码这个接口会慢一点，合成图片这个接口会慢一点，这两个地方有影响；
我只做过后台的，幸亏量不大，要不然服务器根本顶不住。
还是前台来做吧。

不过一般 2-3 秒吧，生成小程序码 1.5s ，合成图片 1.5s.另外小程序码后台存表里，不用每次都请求微信接口。

合成的图片也可以存表里，或者做缓存，我们是存表里的，因为图片上的内容不是经常发生改变的。

@Molita #12 你们前端太水了 canvas 哪来的兼容性问题

不谈前后端，只是图片拼接，速度有点慢了。

@donething 你把 python 的性能压榨完了就换语言? 不懂的人哪怕换汇编还是一个样