文章摘要moonshot-v1-8k
Standby API Responsing..
前情提要
前不久在 jeffer 的一篇文章看到写了一个wp的rss阅读插件,有点小心动。其实早在去年就和 thyuu 交流过这个wp的友链rss功能,当时老哥很快搞定了,还分享了实现代码。当时对rss不是很感冒,基本就是在友链页面翻翻经常逛的那几个,想着也不是每个人都有这个就感觉有点没必要,而且可以直接去看友链的公共聚合之类的,就没弄。直到现在,用了就感觉,欸 好像还挺方便的。

实现
需求是这样的:在wp原生链接基础上,读取不同分类链接中的 link_rss 数据然后解析为自定义 stdClass 返回并储存到 wp_options 表中(方便后期排序等操作),通过不同的链接分类,可以读取不同分类下的rss数据集,通过设置链接显示状态(visible)来限制已订阅链接。
基本理念就是读取和解析xml文件,不过这大千世界,rss种类也很多,面对多种数据结构需要手动去兼容返回。刚开始直接就问了kimi给了一套方案,用php自带的simplexml扩展来解析数据,试了 能用,不过需要自己手动兼容rss类型,就相对比较麻烦。后来想起 thyuu 之前用的wp原生功能 fetch_feed 能自动解析,效果感觉比 curl 好使..
后面尝试了两种不同输出的效果,虽然大差不差但还是wp原生的用起来更稳定(貌似),后面把数据缓存到 wp_option 表了,并挂载更新到了原生链接操作hook(增删改均可同步更新对应分类),添加 wp_schedule 定时清理所有分类缓存任务。
效果
综合效果还是不错的,如图。

问题
主要有两个问题,一个是rss 抓取时间过长,另一个是抓取成功率问题。
- 抓取时效性
- 抓取成功率
关于 rss 抓取时效方面,从拉数据到缓存50+的链接需要反应大概2分钟左右。我问了kimi很多解决方案,什么异步、分块、多线程等等,效果都不太理想。
抓取成功率方面,我试了下当链接超过一定量时就会出现抓取失败的情况,有些报错是数据没完全接收。针对这一情况,首先尝试了 curl_multi 多线程处理,基本没效果。然后尝试将rss链接集分块请求处理,效果不理想。
综上所述,目前还是用的默认 fetch_feed 做的分块请求处理。有没有大佬来指点一二,这种数据应该怎么处理以性能最大化?
闲聊
tmd我前几天手贱给笔记本换硅脂,中毒了去看什么硅脂视频,tmd就是一坨大便艹。换完直接屏幕闪屏,一旦请求gpu上来就开始闪,以为gpu核心出问题了,换核显结果一样。。网上搜了一圈发现可能是显示器线材问题,于是外接显示器最后发现是笔记本显示器的问题。。。这tmd百思不得其解
最要命的是,换了硅脂,笔记本发热降频???我tmd合着搁着绕圈子呢,何况之前根本不降频,温度比这更高高负载时间也比这更长,我干,到底什么原因。我现在就怕这核心被我搞了,但按理来说我拆装非常小心所以不应该啊,哎日了狗,黑神话也搁置了,全怪自己手贱啊,非要去换sb硅脂,这就叫没事找事!!
评论留言

好像还不错
咱俩换硅脂的时间挺同步的,我这换下来感觉没多大变化,风扇声音小了不少。硅脂涂的也是一塌糊涂。
企业可以借助对 WhatsApp 工具的了解来识别沟通瓶颈,从而增强客户服务流程和响应时间。
更多信息
WhatsApp 数据
https://wsdatab.com
好棒!!!!!但是我现在发现一个更好用的!follow真的不错还是免费的,可惜是内测版,白嫖到一个号等我用用来反馈哈哈哈哈哈哈哈哈哈https://app.follow.is/feeds/all/pending?view=0
你的评论区才发现竟然是用的Valine!数据存在哪里leancloud么?
curl多线程还是有效果的,可能我自己友链不多感觉不到慢。也许你可以一批一批的抓取,最后再一起处理,就是会更长时间,可能成功率会高一些。
之前我也是换完闪屏,然后拍了几下就好了,到现在也没出问题
我那个插件不少毛病。不想弄了又,一个大坑挖出来,
,功能越多坑越大。我当时应该把功能设计简单点。遇码不行,就上cluade。
硅脂涂多涂少都不行的
rss 抓取WP不知道是怎么运作的,但你是看的时候才抓取吧,看下能不能设个定时挂后台自己抓吗,比如凌晨的时候,要看的时候都缓存好了
系统不报警不换硅脂。
为啥要换硅脂呢?
这个东西我是起个服务去抓取,扔到 json 里,wp 就纯粹加载文件来展示。
评论 [724] 
用个第三方工具,加载获取rss存json,然后再加载到博客,这个可以再缓存
是给自己的站安一个RSS订阅器吗?


