Skip to content

Latest commit

 

History

History
106 lines (82 loc) · 4.84 KB

README.md

File metadata and controls

106 lines (82 loc) · 4.84 KB

CloudWeGo-Netpoll

中文

Release WebSite License Go Report Card OpenIssue ClosedIssue Stars Forks

Introduction

Netpoll is a high-performance non-blocking I/O networking framework, which focused on RPC scenarios, developed by ByteDance.

RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard library net is designed for blocking I/O APIs, so that the RPC framework can only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching, due to a large number of goroutines under high concurrency. Besides, net.Conn has no API to check Alive, so it is difficult to make an efficient connection pool for RPC framework, because there may be a large number of failed connections in the pool.

On the other hand, the open source community currently lacks Go network libraries that focus on RPC scenarios. Similar repositories such as: evio, gnet, etc., are all focus on scenarios like Redis, HAProxy.

But now, Netpoll was born and solved the above problems. It draws inspiration from the design of evio and netty, has excellent Performance, and is more suitable for microservice architecture. Also Netpoll provides a number of Features, and it is recommended to replace net in some RPC scenarios.

We developed the RPC framework Kitex and HTTP framework Hertz based on Netpoll, both with industry-leading performance.

Examples show how to build RPC client and server using Netpoll.

For more information, please refer to Document.

Features

  • Already

    • LinkBuffer provides nocopy API for streaming reading and writing
    • gopool provides high-performance goroutine pool
    • mcache provides efficient memory reuse
    • IsActive supports checking whether the connection is alive
    • Dialer supports building clients
    • EventLoop supports building a server
    • TCP, Unix Domain Socket
    • Linux, macOS (operating system)
  • Future

    • multisyscall supports batch system calls
    • io_uring
    • Shared Memory IPC
    • Serial scheduling I/O, suitable for pure computing
    • TLS
    • UDP
  • Unsupported

    • Windows (operating system)

Performance

Benchmark should meet the requirements of industrial use. In the RPC scenario, concurrency and timeout are necessary support items.

We provide the netpoll-benchmark project to track and compare the performance of Netpoll and other frameworks under different conditions for reference.

More benchmarks reference kitex-benchmark and hertz-benchmark.

Reference