There’s plenty of web server libraries for the ESP-32, and I am in no position to say which one is the best, since I honestly have no idea. I do know, however, that many tutorials and examples use either ArduinoHttpServer or WebServer, and I got curious if there was any significant performance difference between the two, so I decided to make a quick and dirty benchmark to compare the two. The results I got suggest that WebServer is a bit better when dealing with a large number of small requests, but due to lazy methodology, the confidence of this finding is very low.
The libraries
Here are the contents of library.properties file of both libraries. I omitted the e-mail addresses of the authors to prevent spammers from getting hold of them. You can find the addresses in the actual library.properties files when you download the libraries.
name=WebServer
version=2.0.0
author=Ivan Grokhotkov
maintainer=Ivan Grokhtkov <(...)>
sentence=Simple web server library
paragraph=The library supports HTTP GET and POST requests, provides argument parsing, handles one client at a time.
category=Communication
url=
architectures=esp32name=ArduinoHttpServer
version=0.10.0
author=Sander van Woensel <(...)>
maintainer=Sander van Woensel <(...)>
sentence=Server side minimalistic HTTP protocol implementation.
paragraph=Just the raw HTTP server protocol for the Arduino platform, the rest is left to your imagination.
category=Communication
url=https://github.com/QuickSander/ArduinoHttpServer
architectures=*
repository=https://github.com/QuickSander/ArduinoHttpServer.git
depends=Base64Methodology
I created a very simple web application for the ESP-32, which has a testing endpoint that simply replies “OK” to every request, and also serves an index page with some JavaScript to generate a large number of requests for that endpoint. The script uses one of the two libraries depending on how you compile it. HTTPS was not used for testing.
The script was uploaded from a PC to my ESP-32-S2 Devkit, which was connected to my home WiFi. I ran the benchmark by navigating to the index page in Firefox on the PC. Both devices are about 25m away from the router, and the network environment is very much congested, which definitely impacted the results (this is not exact science).
I performed the benchmark by first compiling the script to use WebServer, and uploading it to the devkit module, then making two measurements: about 200 requests with interval 100ms, and then about 600 requests with interval 50ms. I later repeated the same steps with ArduinoHttpServer version of the script. I did not restart the module between 50ms and 100ms tests, but it was restarted between WebServer and ArduinoHttpServer due to a new script being flashed.
Results
Here is the combined screenshot of all the tests. It has one extra case, when I accidentally uploaded the WebServer version of the script with debug logging set to “Verbose”. I decided to include it just to show how much writing to the serial port can slow down the application. The benchmark script collected the following data (all time values are in milliseconds):
- Requests: the total number of requests made during the test.
- Errors: how many errors
(!response.ok)were recorded during the test. - Time min: the shortest response time recorded during the test.
- Time max: the longest response time recorded during the test.
- Time avg: the average response time from the last 1000ms of the test.
- Reqs/s: how many requests were handled in the last 1000ms of the test.
| WebServer | ArduinoHttpServer | |
| 100ms time min [ms] | 14 | 18 |
| 100ms time max [ms] | 265 | 759 |
| 50ms time min [ms] | 11 | 17 |
| 50ms time max [ms] | 228 | 755 |
Conclusion
It looks like WebServer is a bit faster for this one specific use case that I tested. However, this was just a quick and dirty test, and I did not account for basically anything. The results I got may be distorted by WiFi congestion, devkit firmware quirks, me using the ArduinoHttpServer library in a suboptimal way, or many other factors.
The script
Click the link below to download:
Thank you for reading.