Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
Found the internet!
Posts
Communities

Posts about Actix

Subreddit Icon
r/actix
849 members
A powerful, pragmatic, and extremely fast web framework for Rust
Visit
Subreddit Icon
r/rust
203k members
A place for all things related to the Rust programming language—an open-source systems language that emphasizes performance, reliability, and productivity.
Visit
Subreddit Icon
r/learnrust
11.6k members
This subreddit is for asking questions about the the programming language Rust
Visit
Subreddit Icon
r/programming
4.7m members
Computer Programming
Visit
109
Subreddit Icon
•Posted by12 days ago
109
17 comments
28
18
Subreddit Icon
•Posted by4 days ago
18
2 comments
27
Subreddit Icon
•Posted by11 days ago
27
3 comments
21
Subreddit Icon
•Posted by3 months ago

Hi,

I have an actix web server running (release) on a c5.large linux instance (2 vCPU and 4 GB mem). While running the benchmark from the instance itself (locally), I am getting around 64,000 req/sec.

Testing from the instance itself

However, when accessing the same endpoint through internet (from my local machine), I am only able to clock ~1,100 req/sec

Testing over the internet

On the other hand, I've deployed a simple nodejs - express application as well.

Locally benchmarking the express server produces these results -

Nodejs - locally on the instance

Benchmarking through the internet -


Nodejs - through the internet

It's doing the same req/s as the actix-web, which is almost 15x faster when benchmarked locally.

Why is it so?

Does that mean - this actix-web server can only handle a max of 1100 requests/sec for a simple hello world response? Or does it have to do something with the way `wrk` benchmarks?

In a hypothetical scenario, if 60,000 people make a request to my endpoint at the same time, what would be the result?

21
32 comments
36
Subreddit Icon
•Posted by2 months ago

https://github.com/jacob-pro/actix-extensible-rate-limit

Recently I've written a new rate limit middleware for Actix-Web.

You may be asking - why do need another crate?

The initial motiviation is that a lot of the existing crates unfortunately don't seem to be maintained / up to date with the latest actix web 4.0

But the primary benefit is that I was finding using some of the existing crates quite restrictive, they seem to be designed for very specific use cases, and difficult to extend if you want to do something different.

This crate is intended to support both basic and complex scenarios:


  • Derive a custom rate limit key from the request context (based on a header, client IP address, a request path, combination of these, or implement it yourself with an arbitrary future)

  • You can pass in dynamic rate limits and intervals based on the request context, for example you could write a future that maps user id to particular RPS limit, and pass this to the rate limiter.

  • In-memory and redis backends are provided, but you can also implement your own backend if you want to do something different.

  • You can set a custom 429 response, and you can choose to transform response headers based on the rate limit result (e.g adding x-ratelimit-remaining).

  • You can choose to roll back a rate limit count after the request has completed based on the response code. E.g. you may not want 5xx errors to count against a user's rate limit.


I would be glad to hear any feedback / suggestions :)

36
2 comments
13
Subreddit Icon
•Posted by2 months ago
13
0 comments
61
Subreddit Icon
•Posted by5 months ago
61
74 comments
Reddit and its partners use cookies and similar technologies to provide you with a better experience.By accepting all cookies, you agree to our use of cookies to deliver and maintain our services and site, improve the quality of Reddit, personalize Reddit content and advertising, and measure the effectiveness of advertising.By rejecting non-essential cookies, Reddit may still use certain cookies to ensure the proper functionality of our platform.For more information, please see our Cookie Notice and our Privacy Policy .