You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/monolake/Architecture/context.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,9 @@
2
2
title: "Context Management"
3
3
linkTitle: "Context"
4
4
weight: 4
5
-
description: "Deep dive into Monolake's io_uring-based runtime and performance characteristics compared to traditional event-based runtimes"
6
5
---
7
6
8
-
# Context Management with `certain_map`
7
+
# `certain_map`
9
8
10
9
In a service-oriented architecture, managing the context data that flows between different services is a critical aspect of the system design. The [`certain_map`](https://docs.rs/certain-map/latest/certain_map/) crate provides a powerful way to define and work with typed context data, ensuring the existence of required information at compile-time.
Copy file name to clipboardExpand all lines: content/en/docs/monolake/Architecture/runtime.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,15 +20,16 @@ One of the defining characteristics of Monoio is its thread-per-core architectur
20
20
When working with asynchronous I/O in Rust, understanding the underlying mechanisms of different runtimes is crucial. Two prominent approaches are the io-uring-based runtimes(Monolake) and the traditional event notification based runtimes (Tokio, async-std) which use mechanisms like kequeue and epoll. The fundamental difference between these two models lies in how they manage resource ownership and I/O operations.
21
21
22
22
io_uring operates on a submission-based model, where the ownership of resources (such as buffers) is transferred to the kernel upon submission of an I/O request. This model allows for high performance and reduced context switching, as the kernel can process the requests asynchronously. When an I/O operation is completed, the ownership of the buffers is returned to the caller. This ownership transfer leads to several implications:
23
-
1. Ownership Semantics: In io-uring, since the kernel takes ownership of the buffers during the operation, it allows for more efficient memory management. The caller does not need to manage the lifecycle of the buffers while the operation is in progress.
24
23
25
-
2. Concurrency Model: The submission-based model allows for a more straightforward handling of concurrency, as multiple I/O operations can be submitted without waiting for each to complete. This can lead to improved throughput, especially in I/O-bound applications.
24
+
1.**Ownership Semantics**: In io-uring, since the kernel takes ownership of the buffers during the operation, it allows for more efficient memory management. The caller does not need to manage the lifecycle of the buffers while the operation is in progress.
25
+
26
+
2.**Concurrency Model**: The submission-based model allows for a more straightforward handling of concurrency, as multiple I/O operations can be submitted without waiting for each to complete. This can lead to improved throughput, especially in I/O-bound applications.
26
27
27
28
In contrast, Tokio employs systems like kequeue and epoll. In this model, the application maintains ownership of the buffers throughout the lifetime of the I/O operation. Instead of transferring ownership, Tokio merely borrows the buffers, which has several implications:
28
29
29
-
1. Buffer Management: Since Tokio borrows buffers, the application is responsible for managing their lifecycle. This can introduce complexity, especially when dealing with concurrent I/O operations, as developers must ensure that buffers are not inadvertently reused while still in use.
30
+
1.**Buffer Management**: Since Tokio borrows buffers, the application is responsible for managing their lifecycle. This can introduce complexity, especially when dealing with concurrent I/O operations, as developers must ensure that buffers are not inadvertently reused while still in use.
30
31
31
-
2. Polling Mechanism: The polling model in Tokio requires the application to actively wait for events, which can result in increased context switches and potentially less efficient use of system resources compared to the submission-based model of io-uring.
32
+
2.**Polling Mechanism**: The polling model in Tokio requires the application to actively wait for events, which can result in increased context switches and potentially less efficient use of system resources compared to the submission-based model of io-uring.
The Service pattern is a fundamental abstraction in network programming, popularized by the Tower library in the Rust ecosystem. At its core, a Service represents an asynchronous function that processes requests and returns responses. This pattern is particularly powerful for building networking applications as it enables:
Copy file name to clipboardExpand all lines: content/en/docs/monolake/Getting Started/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ description: "This page provides a quick start guide for setting up and running
8
8
9
9
## Prerequisites
10
10
11
-
-**Linux Kernel Support**: IO-uring requires a Linux kernel version that has io_uring support. Generally, kernel versions 5.1 and above provide the necessary support. Ensure that your target system has an appropriate kernel version installed. Monolake will fall back to epoll on Mac OS.
11
+
-**Linux Kernel Support**: io_uring requires linux kernel support. Generally, kernel versions 5.1 and above provide the necessary support. Ensure that your target system has an appropriate kernel version installed. Monolake will fall back to epoll on Mac OS.
12
12
-**Rust nightly**: See the "Rust installation section" below
@@ -57,15 +50,11 @@ Change packet size with a fixed concurrency of 100.
57
50
58
51
| Crate | Description |
59
52
|-------|-------------|
60
-
|[monoio-transports](https://github.com/monoio-rs/monoio-transports)| A foundational crate that provides high-performance, modular networking capabilities, including connectors and utilities for efficient network communications |
61
-
|[service-async](https://github.com/ihciah/service-async)| A foundational crate that introduces a refined Service trait with efficient borrowing and zero-cost abstractions, as well as utilities for service composition and state management |
62
-
|[certain-map](https://github.com/ihciah/certain-map)| A foundational crate that provides a typed map data structure, ensuring the existence of specific items at compile-time, useful for managing data dependencies between services |
|[monoio-http](https://github.com/monoio-rs/monoio-http)| Monoio native, io_uring compatible HTTP/1.1 and HTTP/2 implementation |
65
-
|[monoio-nativetls](https://github.com/monoio-rs/monoio-tls)| The native-tls implementation compatible with monoio |
66
-
|[monoio-rustls](https://github.com/monoio-rs/monoio-tls)| The rustls implementation compatible with monoio |
67
-
68
-
## Blogs
69
-
70
-
-[Monolake: How ByteDance Developed Its Own Rust Proxy to Save Hundreds of Thousands of CPU Cores](TODO)
71
-
-[Monolake open source summit](TODO)
53
+
|[monoio-transports](https://crates.io/crates/monoio-transports)| A foundational crate that provides high-performance, modular networking capabilities, including connectors and utilities for efficient network communications |
54
+
|[service-async](https://crates.io/crates/service-async)| A foundational crate that introduces a refined Service trait with efficient borrowing and zero-cost abstractions, as well as utilities for service composition and state management |
55
+
|[certain-map](https://crates.io/crates/certain-map)| A foundational crate that provides a typed map data structure, ensuring the existence of specific items at compile-time, useful for managing data dependencies between services |
In this guide, we'll walk through the process of implementing a HTTP routing service using the [monolake-services](TODO) crate. This service will handle incoming HTTP requests and route them to appropriate upstream servers based on the configured routes and their associated endpoints.
8
+
In this guide, we'll walk through the process of implementing an HTTP routing service using the `monolake-services` crate. This service will handle incoming HTTP requests and route them to appropriate upstream servers based on the configured routes and their associated endpoints.
0 commit comments