<div class="key-takeaways"><ul><li>rekuiper ควบคุมหน่วยความจำให้คงที่ระหว่าง 5-10 MB ภายใต้ภาระงานหนัก</li><li>ประมวลผลข้อมูล MQTT ได้สูงถึง 100,000 ข้อความต่อวินาทีบนซีพียูเพียง 1 คอร์</li><li>สถาปัตยกรรมจัดการหน่วยความจำอิงตามจำนวนอุปกรณ์ ไม่ใช่จำนวนข้อความ</li><li>รองรับ REST API และไวยากรณ์ SQL ของ LF Edge eKuiper ทั้งหมด</li></ul></div><p>การวัดประสิทธิภาพงานประมวลผลสตรีมส่วนใหญ่มักมุ่งเน้นไปที่ตัวเลขเพียงชุดเดียว นั่นคือปริมาณงานสูงสุดบนเซิร์ฟเวอร์ขนาดใหญ่ แต่ตัวเลขดังกล่าวแทบไม่มีประโยชน์สำหรับอุปกรณ์ที่เอนจินเหล่านี้ต้องทำงานจริง เช่น เกตเตรย์อุตสาหกรรม ฮับ ESPHead หน่วยหัวรถยนต์ หรือเครื่องชาร์จรถยนต์ไฟฟ้า ซึ่งมักมีซีพียูเพียงหนึ่งหรือสองคอร์และหน่วยความจำฟรีเพียงไม่กี่ร้อยเมกะไบต์ ขณะที่ข้อมูลขาเข้ามุ่งหน้าผ่าน MQTT และมักจะมาแบบกระชากอย่างรุนแรงเมื่อยานพาหนะหรืออุปกรณ์จำนวนมากเชื่อมต่อกลับเข้ามาพร้อมกันหลังเกิดเหตุขัดข้อง</p><p>ในสภาพแวดล้อมเช่นนี้ มีคำถามสำคัญสองข้อที่เป็นตัวกำหนดความอยู่รอดของไปป์ไลน์ข้อมูล ซึ่งไม่ใช่ปริมาณงานสูงสุดอย่างแน่นอน ทีมงานจึงได้พัฒนาเอนจินสตรีมชื่อว่า rekuiper ขึ้นมาเพื่อตอบโจทย์ทั้งสองข้อ และสร้างเกณฑ์มาตรฐานที่ตรงไปตรงมาเพื่อตรวจสอบความสำเร็จ โดยบทความนี้พูดถึงเกณฑ์มาตรฐานพอๆ กับตัวเอนจินเอง เนื่องจากมันช่วยเปิดเผยข้อผิดพลาดในการทำงานที่การทดสอบวัดแต่ความเร็วมักจะมองข้ามไป</p><div class="stat-row"><div class="stat-item"><span class="stat-number">100k</span><span class="stat-label">ข้อความต่อวินาทีบน 1 คอร์</span></div><div class="stat-item"><span class="stat-number">5-10 MB</span><span class="stat-label">การใช้แรมของ rekuiper</span></div><div class="stat-item"><span class="stat-number">0.5-1 GB</span><span class="stat-label">การใช้แรมของเอนจินภาษา Go</span></div></div><p>ผลลัพธ์สำคัญคือจากการทดสอบเวิร์กโหลด MQTT ห้าแบบจำลองการใช้งานจริง rekuiper สามารถผลิตผลลัพธ์ที่ถูกต้องและครบถ้วนที่ 100,000 ข้อความต่อวินาทีบนซีพียู 1 คอร์ในทุกเวิร์กโหลดโดยไม่พบขีดจำกัดสูงสุด แต่ผลลัพธ์ที่น่าสนใจยิ่งกว่าคือในเวิร์กโหลดแบบมีหน้าต่างเวลา (windowed workloads) หน่วยความจำของ rekuiper คงที่อยู่ระหว่าง 5 ถึง 10 เมกะไบต์ ในขณะที่เอนจินภาษา Go พุ่งสูงถึงครึ่งกิกะไบต์จนถึงหนึ่งกิกะไบต์ หรือไม่ก็ล้มเหลวไปเลย ช่องว่างดังกล่าวเกิดจากการออกแบบ ไม่ใช่ภาษาที่ใช้เขียน</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/rekuiper_rust_edge_mu0f8t29_inline_1_dee5a79f30.jpg" alt="microcontroller iot electronics circuit board" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>rekuiper เป็นเอนจินประมวลผลสตรีมที่พัฒนาด้วยภาษา Rust โดยจำลองการทำงานพื้นผิวของ LF Edge eKuiper ทั้ง REST API, ไวยากรณ์ SQL, นิยามสตรีมและกฎ รวมถึงอินเทอร์เฟซบรรทัดคำสั่ง kuiper เป้าหมายคือการใช้งานร่วมกันได้โดยไม่ต้องเขียนโค้ดใหม่ทั้งหมด ผู้ใช้ที่คุ้นเคยกับ eKuiper อยู่แล้วจะสามารถใช้งาน rekuiper ได้ทันทีผ่าน API 98 เส้นทางและ 140 การทำงานที่ตรวจสอบเทียบกับ OpenAPI ของ eKuiper</p><div class="ai-insight"><p>การที่ rekuiper เลือกใช้ภาษา Rust ควบคู่กับการออกแบบสถาปัตยกรรมแบบ bounded memory ถือเป็นก้าวสำคัญในการแก้ปัญหาคอขวดของ Edge Computing เนื่องจากอุปกรณ์ IoT มักมีข้อจำกัดด้านฮาร์ดแวร์ การควบคุมการใช้แรมไม่ให้รั่วไหลหรือขยายตัวตามปริมาณข้อความแบบสุ่ม จึงช่วยป้องกันระบบล่มจากการขาดแคลนหน่วยความจำได้อย่างมีประสิทธิภาพ</p></div><p>ความแตกต่างที่สำคัญซ่อนอยู่เบื้องล่างภายใต้หลักการหน่วยความจำต้องจำกัดภายใต้โหลดหนัก การออกแบบหลักสามประการประกอบด้วย:</p><ul><li>ระบบสตรีมบัสภายในกระบวนการที่มีคิวจำกัดต่อผู้สมัครรับข้อมูลรายละ 4,096 รายการ</li><li>แหล่งข้อมูล MQTT ใช้ไคลเอ็นต์ rumqttc รวบรวมข้อมูลเป็นชุดสูงสุด 1,024 รายการเพื่อลดต้นทุนการปลุกสตรีม</li><li>ตัวประเมินผลแบบเพิ่มส่วน (incremental evaluator) ที่คำนวณหน้าต่างเวลาโดยอิงตามจำนวนอุปกรณ์แทนที่จะเก็บบันทึกทุกแถว</li></ul><blockquote class="pull-quote"><p>"หน่วยความจำของ rekuiper คงที่ระหว่าง 5 ถึง 10 MB ในขณะที่เอนจินภาษา Go พุ่งสูงถึงครึ่งกิกะไบต์ถึงหนึ่งกิกะไบต์หรือล้มเหลว"</p><cite>ทีมพัฒนา rekuiper</cite></blockquote><p>สำหรับการจัดการกรณีลิงก์สัญญาณขาดหายเปรียบเสมือนรถยนต์ที่วิ่งเข้าอุโมงค์หรือพื้นที่ห่างไกล ตัวซิงก์สามารถเปิดใช้งานแคชตามตัวเลือกของ eKuiper ได้ โดยบันทึกที่ไม่สามารถส่งได้สำเร็จจะถูกเข้าคิวในหน่วยความจำจนถึงขีดจำกัด ก่อนจะย้ายไปบันทึกยังดิสก์เพจ เพื่อป้องกันข้อมูลสูญหายอย่างเงียบๆ</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/ankurpaan/at-the-edge-the-number-that-matters-is-memory-not-throughput-specially-in-ramageddon-5hc7" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>rekuiper maintains stable memory usage between 5-10 MB under heavy load</li><li>Processes up to 100,000 MQTT messages per second on a single CPU core</li><li>Memory architecture scales with device count rather than message volume</li><li>Full compatibility with LF Edge eKuiper REST APIs and SQL dialect</li></ul></div><p>Most stream-processing benchmarks typically optimize for a single metric: peak throughput on a massive server. However, that figure is virtually useless where these engines actually run—such as industrial gateways, ESPHome hubs, vehicle head-units, or electric vehicle chargers. In those environments, you are allocated one or two CPU cores with only a few hundred megabytes of free RAM, while input arrives via MQTT and experiences severe burst traffic as vehicle fleets reconnect simultaneously following an outage.</p><p>In such scenarios, two critical questions dictate whether your data pipeline survives, neither of which is peak throughput. The development team built a stream engine called rekuiper to answer both affirmatively and established a rigorous benchmark to verify their success. This post focuses on the benchmark just as much as the engine itself, as it uncovered runtime correctness bugs that throughput-only tests would have rewarded as fast.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">100k</span><span class="stat-label">Messages per second on 1 core</span></div><div class="stat-item"><span class="stat-number">5-10 MB</span><span class="stat-label">rekuiper memory footprint</span></div><div class="stat-item"><span class="stat-number">0.5-1 GB</span><span class="stat-label">Go-based engines memory footprint</span></div><div class="stat-item"></div></div><p>Across five MQTT workloads modeled after real-world deployments, rekuiper delivered complete and correct output at 100,000 messages per second on a single CPU core across every workload without hitting a ceiling. More importantly, on windowed workloads, rekuiper's memory remained between 5 and 10 megabytes while Go-based engines climbed to half a gigabyte to a full gigabyte or failed entirely. That performance gap stems from architectural design rather than the programming language itself.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/rekuiper_rust_edge_mu0f8t29_inline_1_dee5a79f30.jpg" alt="microcontroller iot electronics circuit board" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>rekuiper is a stream-processing engine written in Rust that reimplements the surface interface of LF Edge eKuiper, including its REST API, SQL dialect, stream definitions, and the kuiper command-line utility. The primary goal was seamless drop-in compatibility so existing eKuiper rules and deployment tools continue working without forcing a complete rewrite. The compatibility scope covers 98 REST paths and 140 operations validated against eKuiper's OpenAPI specs.</p><div class="ai-insight"><p>By combining Rust's zero-cost abstractions with a bounded-memory architecture, rekuiper addresses the fundamental bottlenecks of edge computing. Constraining memory growth prevents out-of-memory crashes on resource-constrained IoT hardware, ensuring reliable stream processing during network traffic spikes.</p><p></p></div><p>The core differences lie underneath, anchored by the principle that memory must remain bounded under heavy load. Three specific design choices enable this performance:</p><ul><li>An in-process stream bus featuring bounded per-subscriber queues of 4,096 records each</li><li>An MQTT source utilizing rumqttc to batch incoming publishes up to 1,024 records to reduce scheduling overhead</li><li>An incremental evaluator computing window aggregates based on device count instead of buffering raw rows</li></ul><blockquote class="pull-quote"><p>"rekuiper's memory stayed between 5 and 10 MB while the Go-based engines climbed to half a gigabyte to a full gigabyte, or failed."</p><cite>rekuiper Development Team</cite></blockquote><p>For intermittent connectivity in remote or mobile deployments, sinks can leverage eKuiper options to enable caching. Recoverable send failures route records into FIFO queues—residing in memory up to a threshold before spilling to disk pages to prevent silent data loss during prolonged outages.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/ankurpaan/at-the-edge-the-number-that-matters-is-memory-not-throughput-specially-in-ramageddon-5hc7" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_rekuiper-เอนจินประมวลผลสตรีม-rust-บน-edge-mu0f8t29.jpg

small_rekuiper-เอนจินประมวลผลสตรีม-rust-บน-edge-mu0f8t29.jpg

thumbnail_rekuiper-เอนจินประมวลผลสตรีม-rust-บน-edge-mu0f8t29.jpg

Inewgen

Inewgen

#eKuiper

rekuiper: เอนจินประมวลผลสตรีม Rust บน Edge

Inewgen