search

cdhigh / KindleEar

Aggregates RSS and web content(Calibre recipe), sends to Kindle, and includes an e-ink optimized online reader.
http://cdhigh.github.io/KindleEar/
MIT License
2.73k stars 630 forks source link

跪请作者帮我看一下扣费过多的原因 #658

Closed opptimus closed 2 years ago

opptimus commented 2 years ago

作者你好： 我部署了多台KindleEar，其中一台每次会扣费4美元/月以上，其他多台一般扣费少于0.2美元/月或不扣费，扣费过多的这台费用集中在Backend Instances Salt Lake City这种服务子相（例如这个月就有3.98美元），其他部署的机器也有“Backend Instances Japan”这种高扣费服务，无法进一步展开此类扣费来源清单，所以作者大人能否分析下这类扣费的可能来源？ 我研究了半天，好像这台机器的抓取项目稍多一些，大概42个，但是生成的epub文件并不太大，15.07M。 拜谢之！

cdhigh commented 2 years ago

在我们这个应用来说，网络流量不是问题的关键，就像你说的生成的epub文件并不大，这个文件大小对应则网络流量。 你的应用扣费项目是 Backend Instances (后台实例占用的CPU时间)。

  1. 项目条数过多，这个原因你已经很清楚了；
  2. 对应网站的访问速度较慢或延迟时间较长，导致CPU发出网络抓取请求后等待时间过长（等待时间也算CPU时间，KindleEar应用的默认配置是单线程的，要一个一个链接的排队抓取）；

对此，我也没有更好的方法，可以提一些可能有用也可能没用的“优化方向”：

  1. 减小项目条数
  2. 将不是每天更新的订阅项独立出来，不需要每天尝试去抓取，界面上可以设置一个星期的某天或某几天抓取
  3. 将应用部署到离抓取RSS源网站更近的机房，比将 Salt Lake City 移到 Japan 之类
  4. 在应用的设置界面将自定义RSS的"最旧文章"设置低一些
  5. 有部分没有保留图片必要的订阅源可以尝试不抓取图片
  6. 参考 这个链接 尝试修改module-worker.yaml的instance_class/max_instances/idle_timeout，特别是idle_timeout可以修改短一点的时间，注意修改后的状况可能会更好或更差，因为每个线程都会单独计算CPU时间。
  7. 终极方法是使用GAE新增的API监控应用的限额使用情况，在超限时临时停止应用运行，等下个计费周期再启用（这个就需要你自己研究了，我很多年没有关注GAE了）
opptimus commented 2 years ago

跪谢答主的详细回复！