Closed lancer-wang closed 3 years ago
可能因为你的指令是查3条数据,每个获取一张图,速度还可以 我这边最多查10张,然后获取所有图,速度其实挺慢的
这个也算早期设计问题😂其实现在tag表和tag2illust表都是累赘已经不需要了 之后可以考虑调整下数据表结构了
可能因为你的指令是查3条数据,每个获取一张图,速度还可以 我这边最多查10张,然后获取所有图,速度其实挺慢的
实际上通过pid获取图片实际连接并不是瓶颈,花费时间更多的是下载图片,但如果是使用异步并发的话实际上基本感觉不到差距
使用一个插件测试图片并发下载的速度
test = on_command('test')
@test.handle()
async def __handle(bot: Bot, event: MessageEvent, state: T_State):
image_num_limit = 100
start_t = time.perf_counter()
print(f'==>> Start getting {image_num_limit} image...')
pid_res = await DBPixivillust.rand_illust(num=image_num_limit, nsfw_tag=1)
db_t = time.perf_counter()
print(f'==>> Get DB result, {db_t - start_t}')
pid_list = pid_res.result
tasks = []
for pid in pid_list:
tasks.append(PixivIllust(pid=pid).load_illust_pic())
p_res = await asyncio.gather(*tasks)
dl_t = time.perf_counter()
print(f'==>> Downloaded illust, {dl_t - start_t}')
return p_res
会发现从3张到10张直到25张图片,并没有表现出显著的耗时增加
因此我认为当前表结构及查询逻辑并不是获取图片速度慢的瓶颈因素,我更建议看看是不是服务器的带宽或者代理速度的问题
同时考虑到p站图片真实链接实际上是会根据画师更新作品仅删除作品而变化,因此在数据库中直接写入图片真实链接也并非最优解
当然上面提到的表结构的确有值得优化地方,不过我还得想想怎样去处理作品和图片链接之间的逻辑
暂时先close了
查数据确实不慢,主要是我感觉多请求一次p站挺奇怪的,明明所有的数据都存在于数据库 并发我去研究一下,之前没做过并发
改成异步之后确实快了不少
是的,而且这里要是改数据库表结构的话需要一起更新的东西就太多了,所以暂时就这样不会动
之后可能会添加一些兼容的方法和选项来进行调整吧
我是爬p站的时候顺手给加上了,不过我是没想到,更新你原本的几万条数据比我爬p站花的时间还久....
试了一下,p站删除的作品,实际上在i.pixiv.cat还是存在的,如果存有地址的话,一定程度上不用担心作品被删
为什么建库的时候不顺便存一下图片列表呢,url字段我之前以为是图片,结果是详情页.... 然后由于这个原因,你查库获取图片的时候,只获取了pid,其他的数据是重新获取了一遍, 这个是我修改后的数据库