Should actix-web be converted to salvo-rs for HTTP/3 and WebTransport features and is it feasible? #1472
Replies: 2 comments 6 replies
|
This comment also may be applicable about Apache Iggy's philosophy. #1448 (comment) - though it does say "This is not yet another extension running on top of existing infrastructure, such as Kafka or SQL database" in Apache Iggy's README - keyword "not yet" - maybe SQLPage can help bridge that gap? |
|
Hi @bluelightspirit ! Can you tell us a little bit more about what you are using SQLPage for ? Which specific limitation led you to this proposal ? I suppose the set of people exposing SQLPage directly to the internet without a reverse proxy and the set of people benefiting from the very slight performance improvement and having the technical knowledge to setup http3 do not overlap... |
Good news, SQLPage currently supports this with SSE! |
|
I appreciate your enthusiasm. I think the best way to move forward is build your project with SQLPage, find users, and then push SQLPage in the direction your users need. This reduces the risk of wasting your efforts! |
even more good news! Parquet is supported and I use the standard personally. I would recommend using DuckDB to query parquet files as it comes with a lot of batteries included that make your life super easy! |
|
and ofc +1 to what @lovasoa said. if you run into scaling issues or edge cases, please open an issue with a way we can reproduce it and we can take a look into fixing it :) |
|
I've had trouble setting up GizmoSQL with SQLPage though through ODBC, which uses the DuckDB engine though... I suppose I will make an issue documenting some things I tried now... |
Uh oh!
There was an error while loading. Please reload this page.
SQLPage uses actix-web currently. However, this web framework and many other Rust web frameworks do not have native support for HTTP/3 and WebTransport together from what I found online, except Salvo. Salvo appears to be competitive in speed when compared to actix-web as referenced below per TechEmpower, though not necessarily through http-arena. Actix may be in the top 3 fastest web frameworks according to https://www.http-arena.com/#type=emerging,experimental,flagship but perhaps having WebTransport may be useful for live updates without relying on websockets and HTTP/3 may be useful so packet loss doesn't stall all streams on a single TCP connection through QUIC rather than TCP. Cloudflare at https://blog.cloudflare.com/http-3-vs-http-2/ says HTTP/3 is 12.4% better performance than HTTP/2 if you CTRL+F "12.4% better" on that blog post in question - though only if 0-RTT is used I believe. The Salvo docs at https://docs.rs/salvo/latest/salvo/proto/quinn/crypto/rustls/struct.QuicServerConfig.html says if you set max_early_data_size to u32::MAX, the server will be able to accept 0-RTT data. H3 having WebTransport merged at hyperium/h3#183 is for H3, not Tokio or Hyper.
I did read the discussion at #312 (comment) about a third party server being an option to use for SSE or polling options, however, https://knowledgelib.io/software/patterns/polling-sse-websocket/2026 says WebTransport is the lowest latency out of the short polling, long polling, SSE, WebSocket, and WebTransport options and WebTransport is considered "Cutting edge acceptable" at https://websocket.org/comparisons/, so perhaps SQLPage supporting native WebTransport would allow SQLPage to be more modern?
I also read from #609 (reply in thread) that "However, the current SSE implementation is not for "watching" ongoing changes to the data after the query is done (like subscribing to future changes). It’s just about delivering the results as soon as they are ready. That would be a great and useful feature, but it's not implemented yet." - even if SSE is implemented by now (I don't know if it is) for SQLPage, WebTransport would be a more modern option to support when a browser that supports WebTransport wants to connect to a SQLPage-powered website still.
I also read the suggestion to use DataStar to implement SSE at #975 - however, the Datastar Rust SDK has merely 79 stars at https://github.com/starfederation/datastar-rust so I'm not sure if that's the greatest idea. In my opinion, this would be more viable as part of SQLPage's examples rather than a SQLPage native feature especially since the README of DataStar says "with framework integration for Axum, Rocket, and Warp" without mentioning actix-web, which SQLPage is currently powered by.
The polling mention at #254 (comment) is extraneous it appears as it seems to be a repeat with different words as the comment at #312 (comment).
So in summary, SQLPage using actix-web lacks these from not running Salvo:
Which gives 2 base questions:
Below the "<<<<<<<" is basically my findings which may show me going down a rabbit hole a bit too much in web frameworks here and there - but much of it is not out of scope to talk about.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Random Mozilla widely available baselines such as Array grouping at https://web-platform-dx.github.io/web-features-explorer/features/array-group/ might be out of scope or already implemented for SQLPage when compared to HTTP/3 and WebTransport. The entire list for widely implemented web features are quite long at https://web-platform-dx.github.io/web-features-explorer/widely-available/ and likely beyond the scope of SQLPage in comparison to just discussing such things in Salvo, Axum, ntex, actix-web, or any other web frameworks's GitHub discussions I'd assume... The order of dates they have of the web frameworks also are out of order. Another semi-random random newly available baseline is https://web-platform-dx.github.io/web-features-explorer/features/async-iterable-streams/ to iterate through a stream's incoming data. All of these features probably already are considered by the web framework developers.
The theoretical downside in security is that the actix-web security vulnerabilities discovered before at https://github.com/actix/actix-web/security were moderate while the salvo-rs security vulnerabilities discovered before at https://github.com/salvo-rs/salvo/security were high in terms of severity. However, that doesn't mean for certain actix-web is more secure than Salvo.
There are a few web frameworks with 123,000+ requests per second (512) at https://web-frameworks-benchmark.netlify.app/result?asc=0&order_by=level512 that exist also. However, trying to compile such frameworks into C or C++ may not exactly be as fast as compiling in Nim or Zig directly, plus Rust is strictly memory-safe while Nim, Zig, C, and C++ are not. Nim may be able to compile to JavaScript which is considered memory-safe, but it isn't absolute like safe Rust. Perplexity did tell me Go is memory-safe like Rust despite the difference though. Cyclone also is, but I don't see web frameworks written in Cyclone benchmarked on the lists I found. Vale claims to be completely memory safe, but Perplexity didn't find attribution proof. Cone's memory-safety by default is not unconditionally per the trust keyword. Either way, Vale and Cone also were not on the web frameworks benchmarked lists I can find. Also, Vale is discontinued in favor of Valen at https://github.com/valen-lang/Valen according to the README at https://github.com/ValeLang/Vale in theory.
It should also be noted that Salvo is 99.9% performance in the Cached queries section at https://www.techempower.com/benchmarks/#section=data-r23&test=cached-query in TechEmpower. No other Rust web frameworks come close. Axum is at 46.6%. Single query is where Salvo is only at 85.6% at https://www.techempower.com/benchmarks/#section=data-r23&test=db but that isn't too far off 100% anyway. may-minihttp may be pretty close to the top in Plaintext, Data updates, and Fortunes, while Salvo lags pretty far behind in plaintext, but SQLPage is literally designed for SQL query updates, so Salvo being at 99.9% for Cached queries may allow SQLPage to be used at scale better in theory, no? FaF may be 98.8% performance in Plaintext, but SQLPage is designed for updates, not static pages, right? Also, FaF has 15 "unsafe" keywords at https://github.com/errantmind/faf/blob/master/src/epoll.rs which isn't the greatest to see.
Furthermore, Astra and Viz written in Rust are <10ms latency for Plaintext according to https://www.techempower.com/benchmarks/#section=data-r23&test=plaintext - but caring about latency for Plaintext is probably out of scope for SQLPage. Latency for Fortunes at https://www.techempower.com/benchmarks/#section=data-r23&test=fortune says Salvo, Axum, and ntex are all hand-to-hand. ntex and may-minihttp have poor "Max" ms scores at 8+ ms versus Salvo, Viz, xitca-web, and Axum at 4 ms or less max as well. Even when actix-http and actix-web were in TechEmpower before without magically disappearing since dev.to seemed to have scores available for actix in Round 23 before, actix-http is at 405,144, actix web is at 171,484, and Salvo is at 413,812 for round 22 Fortunes at https://www.techempower.com/benchmarks/#section=data-r22&test=fortune - so actix web apparently just is slow even then. HTTP Arena is broader in tests so actix web being weak for Fortunes but great for HTTP Arena's 27 profiles make it quite complicated to say which is truly "faster" for SQLPage though. Fortunes is a category in http-arena but only trillium, trillium-tuned, and mq-bridge even have such rankings by the GitHub author for Rust-based web frameworks in HTTP/1.1. Even then, Trillium in TechEmpower's Fortunes R23 is at 0.5% performance.
Per a memory safety blog, https://verdagon.dev/blog/when-to-use-memory-safe-part-1:
> Rust goes by borrow checking. Nim goes by reference counting. C and Zig go by manual memory management. Go, originally planned to be systems-programming like, is garbage collected, and so is JavaScript which Nim can compile to.
Now, actix-web and other Rust frameworks may eventually support WebTransport and HTTP/3, especially if Hyper and/or Tokio ever support it natively, however, that is currently not the case.
Cloudflare's quiche to tokio bridger at https://github.com/cloudflare/quiche/tree/master/tokio-quiche referenced in their blog at https://blog.cloudflare.com/async-quic-and-http-3-made-easy-tokio-quiche-is-now-open-source/ may support HTTP/3, but I don't see WebTransport support. There may be a random crate on top of tokio-quiche at https://crates.io/crates/web-transport-quiche and https://github.com/moq-dev/web-transport but the usage of the crates page literally says "To use web-transport-quiche, figure it out yourself lul" so it seems like a joke currently.
Other web frameworks?:
Preface: https://dev.to/tuananhpham/popular-backend-frameworks-performance-benchmark-1bkh says "Only the Fortunes test that’s the most realistic scenario to measure throughput of a backend web. The result is a number of requests per seconds to the database. Quote from Fortunes test specification: The Fortunes test exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding" -> so Fortunes RPS will be focused above all other tests in TechEmpower.
All reactions