Why a reluctant coder chooses OpenACS when other frameworks are so much faster
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:
person-1: 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.. person-2: 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.