@cogitoxin
+1 rime 开启 emijo

@JensenQian 当初就是怕这些云这样费那样费太复杂，才用的 DO，简单直接，看着名气也可以，应该挺稳定的，没想到啊，用了两年多没出啥问题，一出问题就是这种持续几天的问题，好不知道什么时候能解决。

刚刚 ticket 的客服回复，建议我建个新的迁移一下，那我为什么不直接迁移到其他服务商，心累

> Hello there,
>
> Thank you for responding and apologies for the issue you are facing.
>
> I can understand your situation, our engineering team is working continuously to improve stability in SFO2 region but the process requires more time.
>
> We don't have any ETA on this issue at this time, but we can recommend a solution. I understand this isn't something expected. If you continue to see this error while accessing this bucket from the cloud panel, CLI, and other 3rd party tools, we highly recommend you create a new space in sfo3, and migrate the contents objects from your space to the new Spaces. I recommend using rclone for this. Here is a tutorial we have on how to migrate spaces between regions.
>
> https://www.digitalocean.com/community/tutorials/how-to-transfer-digitalocean-spaces-between-regions-using-rclone
>
> When you decide to migrate the contents, kindly let us know to relax your account's default rate limit temporarily so you don't run into rate-limit errors.
>
> Kindly let us know if you have any additional questions.

@xgfan 就是是廉价 VPS 服务商，也不至于功能的可用性都得不到基本保障吧，我还只是单个单个传文件而已，上传的频次非常的低，这连个自建的玩具服务都不如啊。

@xgfan 确定，服务就部署在 DO 同一 region 的服务器上，这两天他们的 API 经常超时，都修复过两次了（见下链接），今天又出现了，真的是烦死了。

1. https://status.digitalocean.com/incidents/mf4dxw8j92kj
2. https://status.digitalocean.com/incidents/dtwbprlz0cnc

不用怀疑自己，有不足就去学

docker swarm + 手动更新镜像 😂

@kestrelBright 那就只能修改 base image 了

ENV 都移到前面，然后合并所有的 RUN 命令

@qwerthhusn 嗯嗯，这个是人工判断的，而我需要的只是一个简单的各图片格式下平衡文件大小和显示效果的经验值

@noobma 可以看看我 append 的链接内容，有程序化的比较方法 😁

@3dwelcome 这个如果用来做在线转换服务，延迟肯定接受不了 😂

@akira 图片是已经压缩了的，大概 1600 宽 1000 高，quality 80 的 webp 图片

@akira 这些都已经做了，这里讨论的是如何设置图片的压缩质量比较合理和通用

@xiaoming1992 👍🏻 刚刚 append 了两篇资料，Adobe 也是讲要保障图片质量，JPG 要在 90-95%，追求文件大小，尺寸在 80% 左右，低于 75% 图片质量将严重下降，不建议，可以作为参考

@ericls 嗯嗯，尺寸的响应式处理已经适配了，目前是图片压缩质量这块，不知道如何确定压缩质量的参数比价合适。扒了一下 Lighthouse 的源码，也没有写这个值，只是根据理论压缩率来比较的

https://github.com/GoogleChrome/lighthouse/blob/c1de7aca060c1f13a82b657780f6a55f0507d9fa/lighthouse-core/audits/byte-efficiency/uses-optimized-images.js#L52-L64

@rekulas 是的，如果是人工处理，可以看图片质量的损失程度来自己决定压缩质量，但是我们图片是程序批量处理的，图片宽高尺寸的问题好解决，只是压缩比例这里，不知道确定多少对所有情况都比较合适。

aws ses, 你值得拥有，mailgun 无故封账号，恶意满满

笔记本才能带着随时加班啊 😂

前端，vscode + docker，方便