Web Frameworks Performance Comparison

Alex Chaplinsky

Last update: Nov 10, 2022

Related tags

Web Applications rails flask sinatra laravel django performance express backend webframework

Overview

Which Web Framework is Faster?

Basic out of the box Web frameworks performance comparison

There are numerous of backend web frameworks for different programming languages. Each of them comes with its own advantages and drawbacks. And it is not a simple task to answer the question "Which framework is the best?". But we can looks at the topic from different perspectives. And performance is a simple metric (yet just one of many) that is measurable and gives an answer to "which framework is faster/fastest?"

The purpose of this project is to attempt to measure a performance of different web stacks as they come out of the box, with no code added.

Results

Test was performed with ApacheBench tool performing 10k requests with concurrency level 10.

ab -n 10000 -c 10 http://127.0.0.1:port

Framework	Web Server	Time taken	Requests per second	Time per request	Longest request
Express	Node.js/http	5.7s	1744.5	5.7 ms	184 ms
Flask	waitress	9.0s	1109.6	9.0 ms	130 ms
Sinatra	Puma 5.4	16.4s	608.8	16.4 ms	239 ms
Django	WSGIServer	21.9s	455.7	21.9 ms	62 ms
Rails	Puma 5.4	138.4s	72.2	138.4 ms	1171 ms
Laravel	nginx	378.5s	26.4	378.5 ms	1042 ms

Note: Ofcourse there are a lot of variables that influence application performance. A lot depends on a web server that you put in front of your application, so numbers above may vary in different configurations. The test was performed with webservers that are typical for the stack just to have a picture of how performance of those frameworks compare to each other.

You can test it yourself

In order to perform tests yourself you'll need to run this project with Docker, so make sure that docker app is installed on your machine.

git clone https://github.com/alchaplinsky/wfpc.git
cd wfpc
docker compose up

Perform tests>

ab -n 10000 -c 10 http://127.0.0.1:port

License

MIT © Alex Chaplinsky

You might also like...

Tugas Kelompok Aplikasi Web Stock Sederhana : Stok Restoran

Tentang Web Ini Web app ini dibuat untuk persyaratan pengumpulan tugas github matakuliah MKPL. web app ini memiliki fitur CRUD stok berbagai jenis mak

3 May 4, 2021

Um chat web feito com HTML, CSS, SASS, JS, PHP e MYSQL

ChatWeb Tecnologias Front-end usadas: Pré processador CSS: Linguagem de programação usada: Projeto hospedado no: Editor de texto usado: Objetivos: Par

4 Oct 27, 2022

amadeus-ws-client: PHP client for the Amadeus GDS SOAP Web Service interface

amadeus-ws-client: PHP client for the Amadeus GDS SOAP Web Service interface This client library provides access to the Amadeus GDS SOAP Web Service i

164 Nov 18, 2022

Koel is a simple web-based personal audio streaming service written in Vue and Laravel

Koel (also stylized as koel, with a lowercase k) is a simple web-based personal audio streaming service written in Vue on the client side and Laravel on the server side. Targeting web developers, Koel embraces some of the more modern web technologies – CSS grid, audio, and drag-and-drop API to name a few – to do its job.

14.3k Jan 4, 2023

The spatial web mapping framework and core-module

Mapbender module This is the Mapbender module, the main-component of the Mapbender application. This module works like a library and can not run for i

74 Dec 25, 2022

Emoncms is an open-source web application for processing, logging and visualising energy, temperature and other environmental data and is part of the OpenEnergyMonitor project.

1.1k Dec 22, 2022

Comments

Inaccurate Laravel performance due to stack mistakes
Hi,

I use Laravel every day, and saw this on Hacker News. So when I saw that the average response time for Laravel was 378.5ms, I wanted to chip in a few comments:

You use nginx as a referse-forward proxy to php serve. php serve has known performance issues when used for anything outside of development. I don't even use it for that, because of its wildly random performance characteristics.

You did not use nginx + PHP-FPM to serve the application. This is a typical server setup, because PHP-FPM provides huge performance boosts over CGI.

You did not disable the xdebug module, which is known to degrade performance 200-500% in performance environments. I have had pages take many seconds, only for them to take 100ms when I turned xdebug off. I think it's because of retaining stack frames, etc.

You also did not boost opcache.max_accelerated_files up to 40000 or more. Laravel uses a large number of files for the framework, so by keeping the default 10k files limit it won't cache everything with each request. See this.

Note: Ofcourse there are a lot of variables that influence application performance. A lot depends on a web server that you put in front of your application, so numbers above may vary in different configurations. The test was performed with webservers that are typical for the stack just to have a picture of how performance of those frameworks compare to each other.

Which makes the above highlighted section absolutely not true for Laravel. Now, to be clear: how you served the application would have negatively skewed any PHP framework's results. I know it was simple to do, but you went against best practices and even default OS-level installs for PHP hosting. Even a basic Apache + PHP set up will average 50-200ms for Laravel with minor optimizations.

Could you please take another look and try to fix how you're bootstrapping the environment?
opened by rk 2