ray VS FrameworkBenchmarks

Compare ray vs FrameworkBenchmarks and see what are their differences.


Debug with Ray to fix problems faster (by spatie)


Source for the TechEmpower Framework Benchmarks project (by TechEmpower)
Our great sponsors
  • SonarQube - Static code analysis for 29 languages.
  • InfluxDB - Access the most powerful time series database as a service
  • SaaSHub - Software Alternatives and Reviews
ray FrameworkBenchmarks
14 321
481 6,863
2.7% 1.1%
7.5 9.8
16 days ago 5 days ago
PHP Java
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of ray. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-10-22.


Posts with mentions or reviews of FrameworkBenchmarks. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-03-18.
  • Is rust overkill for most back-end apps that could be done quickly by NodeJS or PHP?
    8 projects | reddit.com/r/rust | 18 Mar 2023
    Their GitHub wiki explaining the benchmark problems: https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview
  • Python-based compiler achieves orders-of-magnitude speedups
    9 projects | news.ycombinator.com | 15 Mar 2023
    Well, perhaps not 100x in rps, but 10x sure:

    Overall top performing frameworks (JS, Java, and Rust) at 650K rps. That's 7x.

    Top Python based framework: 86K rps.

    A very popular Python framework (flask): 2K rps. That's 325 times worse to the best.

    And that's the "single DB query" benchmark: https://www.techempower.com/benchmarks/#section=data-r21&tes...


  • RJIT a New JIT for Ruby
    5 projects | news.ycombinator.com | 7 Mar 2023
    11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, WSL 2.

    A better benchmark https://www.techempower.com/benchmarks/#section=data-r21&tes...

  • Show HN: Up to 100x Faster FastAPI with simdjson and io_uring on Linux 5.19
    20 projects | news.ycombinator.com | 6 Mar 2023
    How large? Also I'm not sure the gRPC C++ server implementations you've tested are the fastest. If you're comparing to FastAPI (which is more of an HTTP server framework) then you should also compare to what is at the top of https://www.techempower.com/benchmarks/#section=data-r21.
  • You don't need a build step
    9 projects | news.ycombinator.com | 2 Mar 2023
    > And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way!

    As I wrote elsewhere, Dockerfiles are not deterministic. The build artifacts that they produce are deterministic, but that would be comparing a build artifact to a build system.

    > There is another similar ecosystem of mobile apps. That's also way superior in terms of the developer experience.

    Mobile app users have different performance expectations. No one bats an eye if a mobile app takes several minutes to download/update, but a website that does so would be considered an atrocity.

    > And that's not what I am objecting to. My concern is that the core JS specification is so barebones that it fragments right from the start.

    JS is actually really well specified by ECMA. There are so many languages where the formal specification is "whatever the most popular compiler outputs".

    > You make different choices and soon every single JS project looks drastically different from every other project.

    The same could be said of any other moderately complex project written in a different language. Look at the Techempower benchmarks for Java, and tell me those projects all look identical [2].

    > 1. There isn't a standard project format 2. There isn't a single framework that's backward compatible for 5+ years. 3. There isn't even an agreeement on the right build tools (npm vs yarn vs pnpm...) 4. There isn't an agreement on how to do multi-threaded async work

    A lot of the complexity you're describing stems from running in the browser. A server-side js project that returns plain html with a standard templating language is remarkably stable. Express has been on version 4.x.x for literally 9 years [3]. Package.json is supported by yarn, npm, and pnpm. As long as you have a valid lock file and install dependencies using npm ci, you really shouldn't have too many issues running most js projects. I'm not sure what issues you've had with multi-threaded async. The standard for multi-threading in js is web workers (which are called worker threads in node). The js ecosystem is not like Scala or Rust, where's there's tokio and akka. JS uses promises for concurrency, and workers for parallelism.

    [1] https://news.ycombinator.com/item?id=35002815


    [3] https://www.npmjs.com/package/express/v/4.0.0

  • Stack Overflow is a cacheless, 9-server on-prem monolith
    3 projects | news.ycombinator.com | 26 Feb 2023
    Not to take anything away from Dapper (it's an excellent library), but it isn't really that much faster than EntityFramework anymore.

    > EF Core 6.0 performance is now 70% faster on the industry-standard TechEmpower Fortunes benchmark, compared to 5.0.

    > This is the full-stack perf improvement, including improvements in the benchmark code, the .NET runtime, etc. EF Core 6.0 itself is 31% faster executing queries.

    > Heap allocations have been reduced by 43%.

    > At the end of this iteration, the gap between Dapper and EF Core in the TechEmpower Fortunes benchmark narrowed from 55% to around a little under 5%.


    Again, this isn't to take anything away from Dapper. It's a wonderful query library that lets you just write SQL and map your objects in such a simple manner. It's going to be something that a lot of people want. Historically, Entity Framework performance wasn't great and that may have motivated StackOverflow in the past. At this point, I don't think EF's performance is really an issue.

    If you look at the TechEmpower Framework Benchmarks, you can see that the Dapper and EF performance is basically identical now: https://www.techempower.com/benchmarks/#section=data-r21&l=z.... One fortunes test is 0.8% faster for Dapper and the other is 6.6% faster. For multiple queries, one is 5.6% faster and the other is 3.8% faster. For single queries, one is 12.2% faster and the other 12.9% faster. So yes Dapper is faster, but there isn't a huge advantage anymore - not to the point that one would say StackOverflow has tuned their code to such an amazing point that they need substantially less hardware. If they swapped EF in, they probably wouldn't notice much of a difference in performance. In fact, in the real world where apps, the gap between them is probably going to end up being less.

    If we look at some other benchmarks in the community, they tell a similar story: https://github.com/FransBouma/RawDataAccessBencher/blob/mast...

    In some tests, EF actually edges past Dapper since it can compile queries in advance (which just means calling `EF.CompileQuery(myQuery)` and assigning that to a static variable that will get reused.

    Again, none of this is to take away from Dapper. Dapper is a wonderful, simple library. In a world where there's so many painful database libraries, Dapper is great. It shows wonderful care in its design. Entity Framework is great too and performance isn't really an interesting distinction. I love being able to use both EF and Dapper and having such amazing database access options.

  • I Still ‘Lisp’ (and You Should Too)
    4 projects | news.ycombinator.com | 20 Feb 2023
    Clojure is about 2.75x slower than Java, while Python is 5.59x slower.

    The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%.


    About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems:


    But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation):


    I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to you?


  • I love building a startup in Rust. I wouldn't pick it again
    11 projects | news.ycombinator.com | 17 Feb 2023
    In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second.

    Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation.

    I'm pretty sure that maintaining a C++ codebase is less than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc).

    At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1].

    [0]. https://www.techempower.com/benchmarks/#section=data-r21

    [1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

  • De-Bloated Windows 11 Build Runs on 2GB of RAM
    4 projects | news.ycombinator.com | 4 Feb 2023
    Not serving, but handling 2100k requests. Your skepticism is rightly placed, as the HTTP protocol is yet an example of an inefficient protocol that nonetheless is used as the primary protocol on the internet. Some webservers[1] can serve millions of requests pr. second, but I'd never use HTTP in code where efficiency is key.

    No, I'm talking about handling requests. In this particular case, requests (32 to 64 bytes) were flowing through several services (on the same computer). I replaced the processing chain with a single application to remove the overhead of serialization between processes. Requests were filtered early in the pipeline, which made a ~55% reduction in the work needed.

    Requests were then batche into succinct data structures and processed via SIMD. Output used to be JSON, but I instead wrote a custom memory allocator and just memcpy the entire blob on to the wire.

    Before: No pre-filtering, off-the-shelf databases (PSQL), queue system for I/O, named pipes and TCP/IP for local data transfer. Lots of concurrency issues, thread starvation and I/O bound work.

    After: Agnessive pre-filtering, succinct data structures for cache coherence, no serialization overhead, SIMD processing. Can saturate a 32 core CPU with almost no overhead.

    [1] https://www.techempower.com/benchmarks/#section=data-r13&hw=...

  • Looking back on framework benchmark (updates = db writes) what can make Go improved back to be top 10?
    2 projects | reddit.com/r/golang | 2 Feb 2023

What are some alternatives?

When comparing ray and FrameworkBenchmarks you can also consider the following projects:

zio-http - A scala library to write Http apps.

django-ninja - 💨 Fast, Async-ready, Openapi, type hints based framework for building APIs

ray-proxy - a proxy for the Ray app to allow debugging of payloads

LiteNetLib - Lite reliable UDP library for Mono and .NET

C++ REST SDK - The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

drogon - Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows [Moved to: https://github.com/drogonframework/drogon]

SQLBoiler - Generate a Go ORM tailored to your database schema.

Laravel - The Laravel Framework.

CoreWCF - Main repository for the Core WCF project

fastapi - FastAPI framework, high performance, easy to learn, fast to code, ready for production

Spiral Framework - High-Performance PHP Framework

bjoern - A screamingly fast Python 2/3 WSGI server written in C.