[Performance] The delay of sending images

[FuYon]

描述：

经过初步测试，导致这个问题的原因应该和【服务器占用】和【数据库处理效率】有关：

如正在缓存图片时发送指令没有反应的；
使用boom或者同时多人连续发送ero时延迟十分高；

然而我的2h4g服务器测试过过sqlite和mysql，效果都不尽人意，即使占用没有拉满：
有点不应该，mysql的处理速度应该更快才对

单色图延迟

直接描述：发送ero没有反应，过了几分钟或更长时间，bot会把漏下的全发给你。

合成转发消息延迟

不知为何，一旦我使用boom（随机）指令（标准是默认的16张）
bot一定要等十几分钟到一个小时不等（/boom 2 3分钟才发给我）才会转发给你。越少boom越快

总结：

事实上并没有准确的【吞指令】一说，只要延迟够高，就相当于吞了。
多指令--多图片并发 的时候，bot处理会非常非常的慢；同时有可能直接摆烂一个小时。
我其实在本服务器上用过其他bot的色图插件，连续处理5张合并转发的色图只需要3s左右，效率还是很高的。

[cssxsh]

1. 无缓存且数据量小的时候 mysql 并没有 sqlite快
2. 实际上 为了兼容 sqlite 的 单写入 ，我给 SQL 加了一些锁，不过是写入锁，应该不影响
3. boom 指令有 随机 和 指定 tag 两种 模式，使用了哪一种请补充一下
4. 对于 boom 指令来说，开始将${artworks.size}个作品合成转发消息，请稍后... 这个发出之后就SQL查询完成，开始合成转发消息了，我需要知道是转发消息慢还是sql查询慢

[cssxsh]

with https://github.com/cssxsh/pixiv-helper/releases/tag/v1.9.2

remove: PixivImageResource

应该会好不少

[FuYon]

PixivHelper v1.9.1

随机的/boom 指令；
延迟：确认是出现在bot开始合成转发消息...，一般为10min到60min不等。

PixivHelper v1.9.2

环境：使用的还是mysql，重建了一个database；Hibernate配置文件连同release一起更新了一下。
体验：经过初步测试，数据库查询速度没有问题（上达50张），及时响应；转发消息的速度得到了质的飞跃，测试转发50张耗时7-50s左右；转发16张平均耗时1-20s不等。

注明：

转发16张，总共50mb的图片耗时20s左右（其中出现了一张19mb的超大图片）；
转发16张30mb（其中最大图片不超过5mb）左右耗时1s到10s不等。
转发50张的耗时这里我提供3个数据：
1、大小120mb，11s；
2、大小70mb，40s；
3、大小80mb，20s。

初步测试的环境：群内、私聊环境依次发送随机图片的/boom，一旦bot转发完毕立即开始下一轮/boom。

总结：

合成转发消息的速度得到了质的飞跃；
使用体验直线上升。
然而合成转发消息的速度有很大的波动，但都在60s之内。我提供的这几个数据并不能总整体上说明什么，但貌似其速度和图片总大小没有较为明显、直接的关系；总体上来讲，Excellent update!

[cssxsh]

其实还有一个优化点是 同时上传图片，目前是同步顺序上传，可以改成异步并发上传，但是不确定mirai或者腾讯的服务器是否支持这一操作

[FuYon]

可能可行，我之前部署sagiri对接mirai的时候是用到异步的，虽然因为并发数据库被锁之后没用过了（）