เปรียบเทียบ RSS reader แบบ self-hosted บน VPS

RSS reader แบบ self-hosted ตัวใดที่เหมาะกับ VPS ขนาดเล็ก

Miniflux คือ RSS reader แบบ self-hosted ที่ควรติดตั้งบน VPS ขนาดเล็ก โดยเป็นไฟล์ Go binary เพียงไฟล์เดียวที่ทำงานร่วมกับ PostgreSQL รองรับ Fever API และ Google Reader API ทำให้สามารถเชื่อมต่อกับแอปพลิเคชันบนมือถือของบุคคลที่สามได้ และการอัปเกรดทำได้ด้วยคำสั่ง docker compose pull หากคุณต้องการส่วนขยาย (extensions) และต้องการใช้ container เพียงตัวเดียวที่มี SQLite ในตัว ให้เลือกใช้ FreshRSS แทน

RSS reader 5 ตัวที่คุ้มค่าต่อการใช้พื้นที่ดิสก์บน VPS ได้แก่ Miniflux, FreshRSS, CommaFeed, yarr และ Tiny Tiny RSS หน้านี้จะเปรียบเทียบความแตกต่างที่สำคัญระหว่างโปรแกรมเหล่านี้ ได้แก่ ปริมาณหน่วยความจำที่แต่ละ stack ต้องการ, ฐานข้อมูลที่แต่ละตัวบังคับใช้, API สำหรับการซิงค์ที่แอปบนมือถือของคุณต้องการ และสิ่งที่เกิดขึ้นในวันที่มีการอัปเกรด ตัวเลขทั้งหมดในที่นี้เป็นข้อมูลที่เผยแพร่โดยโครงการหรือมาจากการคำนวณพื้นฐาน ซึ่งระบุไว้ในเนื้อหาแล้ว ข้อมูลเหล่านี้ไม่ใช่การทดสอบประสิทธิภาพ (benchmark) ของฮาร์ดแวร์ของคุณ ดังนั้นควรวัดผลด้วยเครื่องของคุณเองโดยใช้ docker stats

ผู้อ่านทั้งห้าท่าน ท่านละหนึ่งย่อหน้า

Miniflux เขียนด้วยภาษา Go และจัดส่งในรูปแบบไฟล์ binary ที่คอมไพล์แบบ static เพียงไฟล์เดียว เอกสารประกอบระบุไว้อย่างชัดเจนถึงข้อกำหนดที่หลีกเลี่ยงไม่ได้เพียงประการเดียวคือ "ทำงานร่วมกับ PostgreSQL เท่านั้น" โดยไม่มีโหมด SQLite ให้ใช้งาน ตัวโปรแกรมมี REST API, Fever API และ Google Reader API รวมถึงรองรับการนำเข้าและส่งออกไฟล์ OPML การค้นหาข้อความแบบเต็ม (full text search) จะถูกจัดการโดย PostgreSQL ซึ่งเป็นเหตุผลว่าทำไมจึงจำเป็นต้องมีฐานข้อมูล

FreshRSS เป็นแอปพลิเคชัน PHP ที่ทำงานในคอนเทนเนอร์เดียวซึ่งรวมทั้งเว็บเซิร์ฟเวอร์และตัวแอปพลิเคชันไว้ด้วยกัน โดยมี SQLite เป็นฐานข้อมูลเริ่มต้นที่ไม่ต้องใช้บริการอื่นเพิ่มเติม ในขณะที่ PostgreSQL และ MySQL จะถูกรองรับสำหรับการติดตั้งขนาดใหญ่ ตัวโปรแกรมรองรับ Google Reader API และ Fever API สำหรับขั้นตอนการติดตั้งได้อธิบายไว้แล้วใน คู่มือการติดตั้ง FreshRSS บน VPS ของเรา ดังนั้นหน้านี้จึงเน้นการเปรียบเทียบแทนการทำซ้ำขั้นตอนการติดตั้ง

CommaFeed พัฒนาด้วย Java บน Quarkus โดยมีเลย์เอาต์ที่เลียนแบบ Google Reader การเลือกฐานข้อมูลจะถูกกำหนดตั้งแต่ขั้นตอน build ไม่ใช่ตอน run time ดังนั้นโปรเจกต์จึงเผยแพร่ image แยกตามฐานข้อมูล ได้แก่ athou/commafeed:latest-h2 สำหรับฐานข้อมูล H2 แบบฝังตัว, athou/commafeed:latest-postgresql สำหรับ PostgreSQL และรุ่นอื่นๆ สำหรับ MySQL และ MariaDB ตัวโปรแกรมเปิดใช้งาน REST API และ Fever API

yarr (yet another rss reader) เป็นไฟล์ binary ภาษา Go เพียงไฟล์เดียวที่ฝัง SQLite มาในตัวและไม่จำเป็นต้องใช้คอนเทนเนอร์ใดๆ โดยใช้คำสั่ง ./yarr เพื่อเริ่มทำงานบนพอร์ต 127.0.0.1:7070 ตัวโปรแกรมมี flag ที่สั้นและเข้าใจง่าย เช่น -addr 0.0.0.0:7070 -auth alice:secret เพื่อเปิดให้เข้าถึงผ่านเครือข่ายโดยมีการป้องกันด้วยรหัสผ่าน และ -db /data/yarr.db เพื่อกำหนดตำแหน่งจัดเก็บฐานข้อมูลตามต้องการ ตัวโปรแกรมรองรับ Fever API โดยเวอร์ชันล่าสุดคือ v2.8 ซึ่งปล่อยออกมาเมื่อเดือนกรกฎาคม 2024 และตรวจสอบเมื่อเดือนสิงหาคม 2026 ดังนั้นจึงควรพิจารณาว่าเป็นซอฟต์แวร์ที่เสร็จสมบูรณ์แล้วมากกว่าที่จะเป็นซอฟต์แวร์ที่มีการพัฒนาอย่างต่อเนื่อง

Tiny Tiny RSS เป็นซอฟต์แวร์ที่เก่าแก่ที่สุดในบรรดาทั้งห้าตัวและใช้ทรัพยากรในการรันสูงที่สุด การตั้งค่าแบบ Docker อย่างเป็นทางการประกอบด้วย 4 บริการ ได้แก่ คอนเทนเนอร์ PostgreSQL, คอนเทนเนอร์แอปพลิเคชัน PHP-FPM, คอนเทนเนอร์สำหรับอัปเดตข้อมูลที่ทำหน้าที่ดึง feed และคอนเทนเนอร์ nginx ที่ทำหน้าที่เป็นหน้าด่าน เอกสารประกอบระบุไว้อย่างชัดเจนว่า "การตั้งค่านี้ใช้ PostgreSQL" ตัวโปรแกรมมี JSON API เป็นของตนเอง ซึ่งแอปพลิเคชันบน Android และแอปพลิเคชันจากภายนอกหลายตัวรองรับการใช้งาน แต่ไม่มีการรองรับ Fever API

ปริมาณหน่วยความจำที่แต่ละ stack ต้องการ

ตัวเลขด้านล่างนี้เป็นงบประมาณ ไม่ใช่ค่าที่วัดได้จริง โดยเป็นเพดานหน่วยความจำที่แต่ละ stack ควรใช้บน VPS ขนาดเล็ก ตัวเลขของ CommaFeed เป็นตัวอย่างที่โครงการเผยแพร่ไว้เอง ซึ่งจำกัด container ไว้ที่ 256 MB ส่วนค่าอื่นๆ เป็นเพดานที่เผื่อพื้นที่ไว้สำหรับตัวดึงข้อมูล (feed fetcher) ซึ่งเป็นส่วนที่ใช้ทรัพยากรสูงขึ้นเมื่อเริ่มรอบการรีเฟรช

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr ใช้หน่วยความจำน้อยที่สุดที่ 128 MB เนื่องจากเป็นไฟล์ binary เดียวและไฟล์ SQLite หนึ่งไฟล์ โดยไม่มี database server หรือ language runtime อื่นรองรับ Miniflux ต้องการ 320 MB สำหรับ 2 containers ซึ่งส่วนใหญ่เป็นของ PostgreSQL ไม่ใช่ของ Miniflux ส่วน Tiny Tiny RSS เป็นกรณีพิเศษที่ 640 MB สำหรับ 4 containers เนื่องจากตัวแอปพลิเคชัน, ตัวอัปเดต, ฐานข้อมูล และเว็บเซิร์ฟเวอร์ เป็นสี่กระบวนการแยกกันที่มี heap แยกกัน

ให้กำหนดค่าเหล่านี้เป็นขีดจำกัดจริง ไม่ใช่แค่ความคาดหวัง การจำกัดหน่วยความจำใน Docker Compose ครอบคลุมถึงไวยากรณ์และสิ่งที่ container จะทำเมื่อถึงเพดานที่กำหนด หาก container ไม่มีการจำกัดหน่วยความจำและเครื่องเต็ม ระบบจะไม่หยุดทำงานอย่างเป็นระเบียบ แต่ kernel จะเลือกกระบวนการหนึ่งมาสังหารทิ้ง ซึ่งบ่อยครั้งกระบวนการที่ถูกเลือกไม่ใช่ container ที่เป็นต้นเหตุของปัญหาหน่วยความจำล้น

ฐานข้อมูลที่ตัวอ่านแต่ละตัวบังคับให้คุณใช้

ฐานข้อมูลคือความแตกต่างด้านการปฏิบัติงานที่ใหญ่ที่สุดระหว่างทั้ง 5 ตัวนี้ ซึ่งเป็นการตัดสินใจที่สำคัญกว่าความแตกต่างในส่วนติดต่อผู้ใช้ เพราะมันเป็นตัวกำหนดขั้นตอนการสำรองข้อมูลและความเสี่ยงในการอัปเกรดของคุณ

PostgreSQL เป็นสิ่งที่ Miniflux และการติดตั้ง Tiny Tiny RSS แบบมาตรฐานต้องการ มันช่วยให้คุณได้ฟีเจอร์การค้นหาข้อความแบบเต็ม (full text search) และการเขียนข้อมูลพร้อมกันอย่างปลอดภัย แต่ต้องแลกมาด้วยการเพิ่ม container อีกหนึ่งตัว, การจัดการ volume และปัญหาที่ต้องเจอซ้ำๆ คือ image ของ PostgreSQL อย่างเป็นทางการไม่สามารถย้ายข้อมูลข้ามเวอร์ชันหลัก (major version) แบบ in-place ได้ เอกสารของ Tiny Tiny RSS ระบุเรื่องนี้ไว้ชัดเจนและเตือนว่า "official PostgreSQL containers ไม่รองรับการย้ายข้อมูลระหว่าง major version" ทางเลือกที่เป็นไปได้ในทางปฏิบัติคือการล็อกเวอร์ชันหลักเดิมไว้ หรือใช้วิธี dump และ restore ด้วย pg_dump และ pg_restore คุณควรวางแผนรับมือเรื่องนี้ทุกๆ 1 หรือ 2 ปี

SQLite เป็นค่าเริ่มต้นของ FreshRSS และ yarr โดยมีลักษณะเป็นไฟล์เดียว ไม่ต้องมีเซิร์ฟเวอร์ ไม่ต้องเปิดพอร์ต และไม่ต้องใช้รหัสผ่าน มันทำงานได้ดีสำหรับผู้ใช้คนเดียวที่มีฟีดจำนวนไม่กี่ร้อยรายการ แต่จะทำงานช้าลงเมื่อมีผู้ใช้หลายคนเขียนข้อมูลพร้อมกัน ซึ่งเป็นจุดที่ตัวเลือก PostgreSQL ของ FreshRSS เริ่มแสดงความคุ้มค่าออกมา ทั้งนี้ yarr ได้เพิ่มการรองรับ PostgreSQL เป็นทางเลือกใน v2.7 แต่การใช้ไฟล์ฝังตัว (embedded file) ยังคงเป็นวิธีมาตรฐานในการใช้งาน

H2 เป็นฐานข้อมูลฝังตัวที่เป็นค่าเริ่มต้นของ CommaFeed และเป็นสิ่งที่ควรพิจารณาก่อนเริ่มต้นใช้งาน เพราะ CommaFeed จะกำหนดฐานข้อมูลตั้งแต่ตอน build image การย้ายจาก H2 ไปยัง PostgreSQL ในภายหลังไม่ใช่แค่การเปลี่ยนการตั้งค่า แต่เป็นการเปลี่ยน image และต้องทำการย้ายข้อมูลด้วยตัวเอง ดังนั้นควรตัดสินใจให้ดีก่อนที่คุณจะมีประวัติการอ่านสะสมอยู่ในระบบนานเป็นปี

แอปบนโทรศัพท์ของคุณจะใช้งานได้หรือไม่

คำถามนี้มีความสำคัญมากกว่าที่หลายคนคาดคิด เนื่องจากอินเทอร์เฟซบนเว็บเป็นเพียงส่วนหนึ่งของการใช้งานโปรแกรมอ่านฟีดเท่านั้น

Miniflux รองรับ API ที่เข้ากันได้กับ Fever และ Google Reader ดังนั้นไคลเอนต์บน iOS และ Android ส่วนใหญ่จึงสามารถเชื่อมต่อได้ FreshRSS ก็รองรับ API สองตัวนี้เช่นกัน โดยเอกสารประกอบของ FreshRSS ได้จัดลำดับไว้ว่า API ของ Google Reader นั้น "ดีที่สุด" เนื่องจากรองรับฟีเจอร์ได้ครบถ้วน ในขณะที่ API ของ Fever มี "ฟีเจอร์จำกัดและมีประสิทธิภาพน้อยกว่า" นอกจากนี้ FreshRSS ยังต้องดำเนินการสองขั้นตอนก่อนที่แอปใดๆ จะล็อกอินได้ คุณต้องเปิดใช้งาน "Allow API access (required for mobile apps)" ในส่วน Authentication จากนั้นจึงสร้างรหัสผ่าน API ในโปรไฟล์ผู้ใช้ การข้ามขั้นตอนการสร้างรหัสผ่าน API จะทำให้เกิดข้อผิดพลาดในการยืนยันตัวตนในแอป ทั้งที่การล็อกอินผ่านเว็บยังคงใช้งานได้ตามปกติ ซึ่งอาจสร้างความสับสนหากไม่ทราบว่าต้องตรวจสอบที่จุดใด

CommaFeed และ yarr รองรับเฉพาะ API ที่เข้ากันได้กับ Fever เท่านั้น จึงใช้งานได้กับไคลเอนต์ที่รองรับ Fever แต่ไม่สามารถใช้กับแอปที่รองรับเฉพาะ Google Reader ได้ ส่วน Tiny Tiny RSS มี API ของตนเอง ซึ่งหมายความว่าคุณต้องใช้ไคลเอนต์ที่พัฒนาขึ้นสำหรับโปรแกรมนี้โดยเฉพาะ โปรดตรวจสอบให้แน่ใจว่าแอปที่คุณต้องการใช้งานรองรับโปรแกรมอ่านฟีดนั้นๆ ก่อนที่คุณจะนำเข้าฟีดจำนวน 300 รายการเข้าไป

ไฟล์ compose ที่ใช้งานได้สำหรับเซิร์ฟเวอร์ขนาด 1 GB

นี่คือ stack ของ Miniflux ซึ่งปรับปรุงจากตัวอย่าง Docker ของโปรเจกต์เอง ณ เดือนสิงหาคม 2026 พอร์ตที่เปิดใช้งานถูกผูกไว้กับ loopback, กำหนด listen address ไว้อย่างชัดเจน และคอนเทนเนอร์ทั้งสองตัวมีการจำกัดหน่วยความจำไว้

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

มีสามบรรทัดในไฟล์นั้นที่ผู้คนมักตั้งค่าผิด LISTEN_ADDR=0.0.0.0:8080 ถูกกำหนดไว้เนื่องจากค่าเริ่มต้นตามเอกสารของ binary คือ 127.0.0.1:8080 และกระบวนการที่ผูกกับ loopback ภายในคอนเทนเนอร์จะไม่สามารถเข้าถึงได้ผ่านพอร์ตที่เปิดไว้ ส่งผลให้เกิดข้อผิดพลาด connection reset ทั้งที่คอนเทนเนอร์ดูเหมือนทำงานปกติ เส้นทาง volume /var/lib/postgresql สอดคล้องกับ PostgreSQL 18; สำหรับเวอร์ชัน 17 และเก่ากว่าจะเก็บข้อมูลไว้ใน /var/lib/postgresql/data การ mount ผิดเส้นทางจะทำให้ไดเรกทอรีข้อมูลไม่ได้อยู่บน volume จริง ส่งผลให้ข้อมูลทั้งหมดหายไปเมื่อคอนเทนเนอร์ถูกสร้างใหม่ 127.0.0.1:8080:8080 ช่วยป้องกันไม่ให้พอร์ตเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ เพราะการเปิดพอร์ตโดยไม่ระบุที่อยู่จะเขียนกฎลงใน chain ที่ ufw ไม่ได้จัดการ Docker ports bypass ufw อธิบายกลไกดังกล่าวไว้ และ a Traefik reverse proxy คือวิธีที่คุณจะนำ TLS มาวางไว้หน้าบริการเหล่านี้

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps ควรแสดงรายการบริการทั้งสองว่ากำลังทำงานอยู่ โดยฐานข้อมูลจะมีสถานะเป็น healthy การเริ่ม Miniflux ครั้งแรกจะบันทึก log การทำ schema migrations ซึ่งเป็นสิ่งที่ RUN_MIGRATIONS=1 เป็นตัวกระตุ้น docker stats --no-stream จะแสดงคอลัมน์หน่วยความจำที่ใช้งานจริง ซึ่งเป็นตัวเลขที่ควรนำไปเปรียบเทียบกับเพดานที่กำหนดไว้ในตารางด้านบน หากคอนเทนเนอร์ Miniflux รีสตาร์ทวนซ้ำ ให้ตรวจสอบ log: connect: connection refused หมายความว่ามันเริ่มทำงานก่อนที่ PostgreSQL จะพร้อมรับการเชื่อมต่อ ซึ่งเป็นสิ่งที่เงื่อนไข service_healthy ป้องกันไว้ ดังนั้นให้ตรวจสอบว่าเงื่อนไขดังกล่าวยังคงอยู่หลังจากการแก้ไขของคุณ หากคุณยังใหม่กับ Compose Docker Compose basics on a VPS จะอธิบายโครงสร้างไฟล์เบื้องต้นก่อน

สิ่งที่อาจไม่สามารถทำงานบนเซิร์ฟเวอร์ขนาด 1 GB ได้

Tiny Tiny RSS เป็นบริการที่ควรหลีกเลี่ยง สแต็กบริการ 4 ตัวตามมาตรฐานของโปรเจกต์นี้สามารถทำงานบน VPS ขนาด 1 GB ได้หาก VPS นั้นไม่ได้รันงานอื่นเลย แต่จะไม่สามารถทำงานร่วมกับแอปพลิเคชันอื่นที่ต้องใช้ฐานข้อมูลและ reverse proxy ได้ การมีบริการ 4 ตัวหมายถึงภาระงาน (overhead) ที่เพิ่มขึ้น 4 เท่า และหนึ่งในนั้นคือ PostgreSQL

CommaFeed สามารถทำงานได้ แต่ต้องใช้ image แบบ H2 และจำกัดหน่วยความจำไว้ที่ 256 MB ตามที่ตัวอย่างของโปรเจกต์ระบุไว้ การจับคู่ที่ทำให้เซิร์ฟเวอร์ขนาดเล็กทำงานไม่ได้คือการรัน JVM ควบคู่ไปกับเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก เนื่องจาก JVM จะใช้ทรัพยากรเท่าที่มีเหลืออยู่ทั้งหมด เอกสารของ CommaFeed ระบุถึง -Xmx256m ว่าเป็นขีดจำกัดสูงสุด และแนะนำ OpenJ9 ว่าเป็น "ทางเลือกที่ประหยัดหน่วยความจำมากกว่า HotSpot JVM" ซึ่งแสดงให้เห็นว่าหน่วยความจำถูกใช้ไปกับส่วนใด

เมื่อเซิร์ฟเวอร์หน่วยความจำเต็ม kernel out of memory killer จะเลือกกระบวนการทำงานหนึ่งขึ้นมาและยุติการทำงานนั้น dmesg -T จะแสดงบรรทัดข้อความที่คล้ายกับ Out of memory: Killed process 1234 (java) และคอนเทนเนอร์จะหายไปจาก docker compose ps โดยไม่มีข้อความแจ้งเตือนใน log ของแอปพลิเคชัน เนื่องจากแอปพลิเคชันไม่เคยมีโอกาสได้เขียนบันทึกใดๆ ลงไป

ลักษณะการอัปเกรดของแต่ละบริการ

• Miniflux: docker compose pull && docker compose up -d โดยจะทำการปรับปรุง schema ของฐานข้อมูลโดยอัตโนมัติเมื่อเริ่มทำงานหากมีการตั้งค่า RUN_MIGRATIONS=1 ไว้ ความเสี่ยงในการอัปเกรดไม่ได้อยู่ที่ตัว Miniflux แต่อยู่ที่เวอร์ชันหลักของ PostgreSQL ที่ใช้งานอยู่เบื้องหลัง
• FreshRSS: ให้ดึง image ใหม่มาใช้งาน ในกรณีที่ใช้ SQLite จะไม่มี engine ของฐานข้อมูลให้ต้องอัปเกรด ดังนั้นปัญหาที่มักพบจึงเกิดจากส่วนขยาย (extension) ของบุคคลที่สามที่ไม่ได้รับการปรับปรุงให้ทันสมัย
• CommaFeed: ให้ดึง image variant ที่ตรงกับฐานข้อมูลของคุณ การเปลี่ยนจาก latest-h2 ไปเป็น latest-postgresql จะไม่สามารถย้ายข้อมูลเดิมของคุณไปได้
• yarr: ให้แทนที่ไฟล์ binary เดิมและเก็บไฟล์ฐานข้อมูลไว้ เนื่องจากไม่มีการออกรุ่นใหม่นับตั้งแต่ v2.8 ในเดือนกรกฎาคม 2024 (ตรวจสอบข้อมูล ณ เดือนสิงหาคม 2026) โดยปกติจึงไม่มีสิ่งใดที่ต้องอัปเกรด
• Tiny Tiny RSS: docker compose pull && docker compose up -d ระบบจะรันการปรับปรุง schema โดยอัตโนมัติ และหน้าจอการใช้งานจะเปลี่ยนเส้นทางไปยังหน้าการปรับปรุงข้อมูลเมื่อจำเป็นต้องมีการยืนยัน

ให้ทำการสำรองข้อมูลฐานข้อมูล (dump) ก่อนดำเนินการเหล่านี้เสมอ ไม่ใช่ทำหลังจากนั้น

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

ต้นทุนด้านแบนด์วิดท์ของช่วงเวลาการรีเฟรช

ตัวเลขด้านล่างนี้เป็นการคำนวณทางคณิตศาสตร์ ไม่ใช่การวัดผลจริง โดยสมมติว่ามีฟีด 100 รายการ มีการร้องขอหนึ่งครั้งต่อฟีดในแต่ละช่วงเวลา และขนาดการตอบกลับอยู่ที่ 40 KB ต่อครั้ง ปริมาณการใช้งานจริงจะต่ำกว่านี้เมื่อเซิร์ฟเวอร์รองรับการร้องขอแบบมีเงื่อนไข (conditional requests) และจะสูงขึ้นเมื่อฟีดมีเนื้อหาบทความฉบับเต็ม

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

ช่วงเวลา 5 นาทีสำหรับฟีด 100 รายการจะเท่ากับ 864,000 ครั้งต่อเดือน และใช้แบนด์วิดท์ประมาณ 34.6 GB ต่อเดือน หากตั้งค่าการดึงข้อมูลรายชั่วโมงจะอยู่ที่ 72,000 ครั้ง และประมาณ 2.9 GB Miniflux มาพร้อมกับการตั้งค่า POLLING_FREQUENCY ไว้ที่ 60 นาที ซึ่งเป็นแถวสุดท้ายของตารางดังกล่าว และค่าเริ่มต้นนี้เหมาะสมสำหรับผู้ใช้ส่วนใหญ่ บทความไม่ได้มาถึงเร็วขึ้นเพียงเพราะคุณร้องขอถี่ขึ้น

การร้องขอแบบมีเงื่อนไขคือสิ่งที่ช่วยให้ตัวเลขจริงต่ำกว่าการคำนวณทางคณิตศาสตร์ โปรแกรมอ่านฟีดที่จัดเก็บ header ETag และ Last-Modified ที่ได้รับจากฟีด จะส่งข้อมูลเหล่านั้นกลับไปในรูปแบบ If-None-Match และ If-Modified-Since หากเซิร์ฟเวอร์ไม่มีข้อมูลใหม่ก็จะตอบกลับด้วย 304 Not Modified โดยไม่มีเนื้อหา (body) การเชื่อมต่อยังคงต้องเสียค่าใช้จ่ายในการทำ handshake แต่ไม่ต้องเสียค่า payload ฟีดที่เพิกเฉยต่อการร้องขอแบบมีเงื่อนไขจะส่งเอกสารทั้งหมดมาให้คุณทุกครั้ง ดังนั้นฟีดขนาดใหญ่เพียงไม่กี่รายการอาจทำให้ค่าใช้จ่ายในการรับส่งข้อมูลของคุณสูงขึ้นมาก

การดึงข้อมูลถี่เกินไปอาจทำให้คุณถูกบล็อกได้ เซิร์ฟเวอร์ที่ตัดสินว่าคุณกำลังรบกวนระบบจะตอบกลับด้วย 429 Too Many Requests และบางเว็บไซต์อาจตอบกลับด้วย 403 แทน Miniflux จะบันทึกข้อผิดพลาดล่าสุดไว้ที่ตัวฟีดนั้นๆ ดังนั้นรายการฟีดจึงเป็นจุดแรกที่คุณควรตรวจสอบเมื่อฟีดรายการใดรายการหนึ่งหยุดอัปเดตในขณะที่รายการอื่นยังคงทำงานได้ตามปกติ

ฟีดหยุดทำงาน และไฟล์ OPML ไม่ใช่การสำรองข้อมูล

ฟีดเสื่อมสภาพเร็วกว่าที่คุณคาดไว้ โดเมนหมดอายุ เว็บไซต์ย้ายไปใช้แพลตฟอร์มที่ไม่มีฟีด และ URL ที่เคยส่งข้อมูล XML กลับเริ่มส่งหน้าแสดงข้อผิดพลาด HTML พร้อมสถานะ 200 OK กรณีหลังนี้เป็นปัญหาที่น่ารำคาญ เพราะการดึงข้อมูลสำเร็จแต่การประมวลผลล้มเหลว ทำให้โปรแกรมอ่านฟีดของคุณบันทึกว่าเป็นข้อผิดพลาดในการประมวลผลแทนที่จะเป็นข้อผิดพลาดของเครือข่าย ให้จัดเรียงรายการฟีดตามการอัปเดตล่าสุดปีละครั้ง และลบฟีดที่เงียบหายไปออก

การส่งออกไฟล์ OPML คือรายการสมัครสมาชิกของคุณ มันเก็บเพียง URL ของฟีดและชื่อโฟลเดอร์ แต่ไม่ได้เก็บสถานะการอ่าน บทความที่ติดดาว การตั้งค่าเฉพาะฟีด กฎการกรอง หรือข้อความในบทความที่คุณบันทึกไว้ หากคุณนำเข้า OPML นั้นไปยังการติดตั้งใหม่ คุณจะได้ฟีดกลับมา แต่บทความทั้งหมดที่คุณเคยอ่านจะถูกทำเครื่องหมายว่ายังไม่ได้อ่านอีกครั้ง

การสำรองข้อมูลที่สำคัญคือฐานข้อมูล สำหรับ PostgreSQL คำสั่ง pg_dump ที่กล่าวถึงข้างต้นคือทั้งหมดที่ต้องทำ สำหรับโปรแกรมอ่านฟีดที่ใช้ SQLite เช่น FreshRSS หรือ yarr ให้หยุดการเขียนข้อมูลก่อนแล้วจึงคัดลอกไฟล์ หรือทำการคัดลอกแบบสอดคล้อง (consistent copy) ขณะที่โปรแกรมทำงานอยู่ด้วย sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" การใช้คำสั่ง cp ธรรมดากับฐานข้อมูลที่กำลังมีการเขียนข้อมูลอยู่อาจทำให้ได้ไฟล์ที่ไม่สามารถเปิดใช้งานได้ในภายหลัง เนื่องจากการคัดลอกอาจเก็บข้อมูลที่เขียนยังไม่เสร็จสมบูรณ์ จากนั้นให้ส่งไฟล์เหล่านั้นออกจากเซิร์ฟเวอร์ตามกำหนดเวลา ซึ่งเป็นหน้าที่ของ การสำรองข้อมูลด้วย restic บน VPS และควรทดลองกู้คืนข้อมูลลงในคอนเทนเนอร์ทดสอบอย่างน้อยหนึ่งครั้งเพื่อให้แน่ใจว่าขั้นตอนการทำงานนั้นถูกต้อง

โปรแกรมอ่านฟีดเป็นหนึ่งในบริการที่ประหยัดที่สุดในการดูแลด้วยตนเอง ซึ่งเป็นเหตุผลว่าทำไมมันจึงปรากฏอยู่ในทุกรายการของ สิ่งที่ควรทำ self-host ในปี 2026 หากคุณติดตั้ง อินสแตนซ์ SearXNG แบบ self-hosted ควบคู่ไปด้วย ทั้งการอ่านและการค้นหาของคุณจะอยู่บนฮาร์ดแวร์ที่คุณควบคุมเองทั้งหมด

FAQ

RSS reader แบบ self-hosted ตัวไหนใช้หน่วยความจำน้อยที่สุด?

yarr ครับ มันเป็นไฟล์ binary ภาษา Go เพียงไฟล์เดียวที่มี SQLite รวมอยู่ภายใน จึงไม่ต้องใช้ database server หรือ runtime อื่นเพิ่มเติม และสามารถทำงานได้ดีภายใต้ขีดจำกัดหน่วยความจำที่ 128 MB สิ่งที่ต้องแลกคือการดูแลรักษาและฟีเจอร์ โดยรุ่นล่าสุดคือ v2.8 เมื่อเดือนกรกฎาคม 2024 และรองรับเฉพาะ Fever API เท่านั้น หากคุณต้องการโปรเจกต์ที่มีการพัฒนาอย่างต่อเนื่องในระดับการใช้ทรัพยากรที่ใกล้เคียงกัน Miniflux ร่วมกับ PostgreSQL ที่ใช้หน่วยความจำ 320 MB จะเป็นคำตอบที่ดีกว่า

ฉันสามารถรัน RSS reader แบบ self-hosted บน VPS ขนาด 1 GB ได้หรือไม่?

ได้ครับ Miniflux ร่วมกับ PostgreSQL ใช้หน่วยความจำรวมประมาณ 320 MB เมื่อคุณตั้งค่า mem_limit ไว้ที่ container ทั้งสองตัว ส่วน FreshRSS ที่ใช้ SQLite สามารถรันได้ใน container เดียว ตัวที่ควรหลีกเลี่ยงบน VPS ขนาด 1 GB คือ Tiny Tiny RSS stack แบบมาตรฐาน ซึ่งประกอบด้วยบริการถึง 4 รายการรวมถึง PostgreSQL ของมันเอง ควรตั้งค่าจำกัดหน่วยความจำเสมอ เพราะหากปล่อยให้ container ใช้ทรัพยากรไม่จำกัดบนเครื่องที่หน่วยความจำเต็ม kernel จะสั่ง kill process ทิ้ง ซึ่งมักจะเป็นตัว database แทนที่จะเป็นตัวแอปพลิเคชันที่เป็นต้นเหตุ

ตัวไหนบ้างที่ใช้งานกับแอป RSS บน iOS และ Android ได้?

Miniflux และ FreshRSS รองรับทั้ง Fever API และ Google Reader API ทำให้แอปบนมือถือเกือบทุกตัวสามารถเชื่อมต่อได้ ส่วน CommaFeed และ yarr รองรับเฉพาะ Fever API เท่านั้น สำหรับ Tiny Tiny RSS จะใช้ API ของตัวเอง คุณจึงต้องใช้แอปที่สร้างมาเพื่อรองรับมันโดยเฉพาะ สำหรับ FreshRSS คุณต้องเปิดใช้งาน API access ในส่วน Authentication และตั้งค่ารหัสผ่านสำหรับ API แยกต่างหากในหน้าโปรไฟล์ มิฉะนั้นแอปจะล็อกอินไม่สำเร็จแม้ว่าการใช้งานผ่านหน้าเว็บไซต์จะยังทำงานได้ปกติก็ตาม

การส่งออก OPML ถือเป็นการสำรองข้อมูล RSS reader ของฉันหรือไม่?

ไม่ครับ OPML เก็บเพียง URL ของฟีดและโฟลเดอร์เท่านั้น จึงทำได้เพียงสร้างรายการติดตามของคุณขึ้นมาใหม่แต่ไม่มีข้อมูลอื่น สถานะการอ่าน, รายการที่ติดดาว, กฎการกรอง และเนื้อหาบทความทั้งหมดจะอยู่ในฐานข้อมูล ให้สำรองข้อมูลตัวฐานข้อมูลโดยตรงด้วย pg_dump สำหรับ PostgreSQL หรือใช้คำสั่ง .backup สำหรับ SQLite แล้วคัดลอกไฟล์ผลลัพธ์ออกจากเซิร์ฟเวอร์

Miniflux รองรับ SQLite หรือไม่?

ไม่รองรับครับ เอกสารของโปรเจกต์ระบุว่า "ทำงานร่วมกับ PostgreSQL เท่านั้น" และฟีเจอร์การค้นหาแบบ full text search ก็ถูกพัฒนาโดยใช้ความสามารถของ PostgreSQL จึงไม่มีโหมดที่เบากว่าให้เลือกใช้ หากคุณต้องการโปรแกรมอ่านฟีดที่ไม่มี container ฐานข้อมูลเลย ให้ใช้ FreshRSS ร่วมกับ SQLite ที่เป็นค่าเริ่มต้น หรือใช้ yarr ที่เก็บข้อมูลในไฟล์แบบ embedded ครับ