Measuring response times for each framework(middleware). Each framework has to have two features; routing and parsing path parameters.
Current target frameworks(middlewares)
- Ruby
- Crystal
- Go
- Rust
- node
- Elixir
- Swift
- C#
- Python
See Development section when you want to add new languages for frameworks.
I want to know the response time, not a usability. So full-stack framework is at a disadvantage.
- Each server has no special logics.
- Each server's executable is named as
server_[Lauguage]_[Framework]
. (For example,server_ruby_sinatra
) - There are only 3 routes
- GET '/' return status code 200 with empty body
- GET '/user/:id' return status code 200 with the id
- POST '/user' return status code 200 with empty body
Required environment -> See Current target frameworks(middlewares)
Neph is a modern command line job processor that can be substitute for make
command.
To compile servers and benchmarker,
> neph
For each language,
> neph -j ruby
For each framework,
> neph -j rails
See neph.yml
To compile servers and benchmarker,
> make
For each language,
> make ruby
For each framework,
> make rails
You can take a benchmark by
> bin/benchmarker
For each language
> bin/benchmarker ruby
For each framework
> bin/benchmarker rails
For comparison (Comparing rails, kemal and router.cr in this example)
> bin/benchmarker rails crystal
If you take it manually, you can run each server by
> bin/server_[Language]_[Framework]
and run client by
> time bin/client
You can set # of threads and # of the loops of the request(there are 3 requests in a loop) by
> time bin/client -t 16 -r 1000
In the above example, 16 threads requests 1000 * 3 times. So 48000 requests are sent in total.
Setup servers by using docker
is in work in progress. Currently, crystal and ruby servers are supported. For example
docker-compose up rails
Then you can run your client by
time ./bin/client
- Give me PR when you want to add other web frameworks
- Give me PR when you can tuning each framework (under the rule)
/[language]/[framework]/[codes]
<- Project iteselfbenchmarker/benchmarker.cr
<- Adding it as a target toREADME.md
<- Adding it as a target framework of the listMakefile
neph.yml
(optional)
Anyway, you don't have to care about details since maintainer can fix them after merging it. The result will be updated by maintainer.
- Fork it ( https://github.com/tbrand/which_is_the_fastest/fork )
- Create your feature branch (git checkout -b my-new-feature)
- Commit your changes (git commit -am 'Add some feature')
- Push to the branch (git push origin my-new-feature)
- Create a new Pull Request
- tbrand Taichiro Suzuki - creator, maintainer