Why a reluctant coder chooses OpenACS when other frameworks are so much faster

car that looks like jet plane without wings

One of the fastest cars in the world. Thrust SSC on display at Coventry Transport Museum, April 2007. image in public domain by AJB83

This post is a continuation of a series on critical reviews by coders of OpenACS. And, what it means as a reluctant coder.

Review: OpenACS is slow. My (fill-in-blank) framework is so much faster.

Good for you. Scalability is about addressing limits of number of concurrent connections and number of requests per second. In some sense, this is an analog of a children’s turtle and rabbit story. The rabbit is so much faster, but then it takes a nap and the turtle wins. Unless your system is well tested in all its complexity at higher capacities, something will break. The system naps. Connections falter or drop. There might not even be a record of it in the logs. Information gets out of sync. Losing data complicates things. This stuff happens when you need it to work the most.

As a reluctant coder, know that there is a certain amount of overhead involved in making things scale. For OpenACS, complex deployments test it every day. OpenACS has tolerable low latency and thoughtful performance tuning parameters for real world situations. Here’s an example: http://openacs.org/forums/message-view?message_id=4074774

In a race of turtles and rabbits, what kind of rabbits are out there? They’re most everywhere. Check out this noble attempt at testing platforms https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=update which doesn’t include having a server log activity. Logging may seem a trivial issue. Yet, most any developer can write a server that is fast enough to ace these tests and still not have a practical application framework. For example, look at this exchange on a wiki page about a Tcl developer having written and tested a server embedded in their code:


I wanted to test various web servers… 
What I found was that 
this trivial tcl based web server is screaming fast. 

Benchmarks on my mac mini (a VERY slow machine):

Max Requests per second handled with a
 "hello world" dynamic tcl test page:

Server, Max requests served per second:

lighttpd-cgi               15/second
tclhttpd                   32/s
aolserver                  640/s [to] 750/s
trivial all-tcl-web-server 1162/s

900 byte image fetch benchmark:

apache image fetch            593/s
aolserver image fetch         1019/s [to] 1267/s
lighthttp image fetch         1089/s
tclhttpd                      69/s
trivial http with image cache 1127/s

Notice the amazing speeds from the trivial tcl server..


Perhaps logging has something to do with it? 
Was logging enabled for the other web servers? 
Also, I'm curious what you changed in the code sample 
to have it serve the images..

(from http://wiki.tcl.tk/15244 )

That says it all.

Imagine if cars represent applications and their frameworks. They work well in town for short trips and few passengers. If you need to transport a bunch of people, vans, buses and trucks transport more faster for less cost. In this analogy, OpenACS is like using a fleet of 8 to 15 passenger four-wheel drive SUVs or a freight train.  It works to run errands around a suburban town. And yet, OpenACS has a higher bar of expectations for use.