fpWeb performance tuning
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
kveroneau · 2016-02-02 00:26

Okay, so I just did a quick Benchmark test using the siege tool of
both fpWeb, and a micro framework from Python.  At first, when using
the standard WSGIRef server, the one which ships with Python, which
isn't multithreaded, the performance was well under that of a threaded
fpWeb.  However, I thought then, the comparison was rather unfair, as
the Python web program was limited to a single thread.  I then
proceeded to use the PasteServer, and to my utter amazement, it beat
fpWeb hands down...  Now, how the heck can an interpreted language
beat a compiled language?  There must be something I am truly missing
in fpWeb to fine tune the overall load it can provide.  How many
threads does it spawn by default?  Is it possible to change the amount
of worker threads in fpWeb?

fpWeb benchmark w/ threading enabled, single page, only displaying the
text "Hello, Pascal!":
Transactions:                   7698 hits
Availability:                  99.55 %
Elapsed time:                 101.03 secs
Data transferred:               0.10 MB
Response time:                  0.59 secs
Transaction rate:              76.20 trans/sec
Throughput:                     0.00 MB/sec
Concurrency:                   44.90
Successful transactions:        7698
Failed transactions:              35
Longest transaction:           35.06
Shortest transaction:           0.00

Single page Bottlepy using the Paste server, displaying only "Hello,
Bottle!":
Transactions:                  19081 hits
Availability:                  99.99 %
Elapsed time:                 100.32 secs
Data transferred:               0.24 MB
Response time:                  0.02 secs
Transaction rate:             190.20 trans/sec
Throughput:                     0.00 MB/sec
Concurrency:                    4.53
Successful transactions:       19081
Failed transactions:               2
Longest transaction:           12.20
Shortest transaction:           0.00

The siege command used: siege -t 101S -c 100 http://localhost:8080/

For my next benchmarking test, I will run both applications behind
Nginx using the FastCGI protocol, although I don't imagine it will
perform any differently.

By all means, fpWeb isn't terrible, without any optimizations, fpWeb
could definitely handle a decent amount of traffic with no issues. 
I'm also sure, if there was more business logic under the hood, that
fpWeb would win over any bytecode language any day.

----------------------------------------------------------------------
Leledumbo · 2016-02-02 01:12

When it comes to server side benchmark, it's not always language that
matters. The underlying technology and protocol could be more
affecting. Paste server uses thread pool, fphttpserver doesn't. I
think that's the biggest factor if you compare multithreaded feature
of a web server. Michael as the author of fpWeb and the underlying
fcl-web package once said he actually never meant the embedded http
server to be used in production, it's mainly for testing due to its
simple execution and ability to debug right from the IDE up to the
deepest part. Using FastCGI behind a capable web server like nginx /
apache (which can spawn as many instances as it wants) should give
better performance.