Lucee vs Node.js for "Enterprise-Class Heavy Lifting"

This topic was prompted by a comment that @Jon_Clausen (who I now see hasn’t been active here since 2016) wrote in Adam Cameron’s blog way back in 2015 when he announced that Lucee had been forked from Railo:

Node and CFML play real well together. Node for your non-blocking data IO and CFML for the enterprise-class heavy lifting and display markup.

My questions are what is the definition of “enterprise-class heavy lifting” and some specific examples of when Lucee is superior to Node for that? Edited for those who don’t have experience with Node: I’ll take whatever insight you can spare for me!

I know it’s only been 2 days since I posted this, but other new topics have been answered in the meantime, so I hope it hasn’t been lost in the shuffle. :wink:

Jon doesn’t typically frequent these forums. He’s much more successful at getting client work done than I am. Darn ADHD, lol. I can ping Jon in case he didn’t get notified of your tag, but he may just be traveling or busy.

I can’t speak to what he meant by that, but I will add that the JVM in general is viewed as being very good for multi-threaded, long running, scalable deployments. HTML templating is a first class citizen of CFML and running on the JVM gives it board support for deployment as well as libraries. I realize many of those things can be said about Node too.

A quick anecdote- when Twitter switched from Ruby on Rails to a Java-based platform I think they got like 3x performance improvements and used 10 times fewer servers (not finding the exact quotes for that right off-- it’s been a few years since I read that) I know more may read that as an indictment of Ruby, but it’s also a huge win for the scalability of the JVM under heavy workloads.

The closest thing I know of to a fair side-by-side tech comparison that batters servers with load running identical apps written in different language and frameworks and then compares them side by side is the Techempower benchmarks. Here you can see raw Lucee and Adobe outperforming raw Node.js and ColdBox MVC on both engines outperforming the Node.js Express framework in a test that makes several DB calls. Heck even ColdBox itself outperformed raw Node.js!

1 Like

And in case anyone was curious since I mentioned Ruby above, CFML Lucee and Adobe and ColdBox ALL beat Ruby on Rails in this test as well :wink: Tip, click the link above and you can play with the filters to choose what languages and frameworks show in the results. It’s super interesting.


@bdw429s pretty much encapsulates exactly what I was getting at in his replies above. Enterprise apps tend to do a lot of processor and memory intensive work - reporting, PDFs, spreadsheets, working with big datasets, lots of concurrency, etc - which is generally more stable and more scalable in a multithreaded environment.


Node.js has been capable of multi-threading via worker_threads since v10.5.0 (stable for production since v12 LTS), which makes me wonder if the TechEmpower rating didn’t account for that.

However, if performance were my sole reason for choosing a (mature and popular) platform, I’d be using (which I despise because of Microsoft, but it has a whopping rating of 19,644!) or php-ngx-postgres (15,030). I have pretty strong experience with PHP, having built a shopping cart from scratch for an online grocery store in Australia ages ago, but I simply do not like its clumsy syntax. I mean, it’s not as bad as the cfml tag syntax (HA!), but I’m a big fan of cfscript and all the functionality of Lucee straight out of the box, the tight Java integration, easy ability to use JSoup and OWASP Java HTML Sanitizer, etc.

Also now I’m wondering how lucee-ngx-postgres would perform …

1 Like

That’s a great question. Techempower just manages the repos-- people from each community submit the test implementation in each language, so it would behoove the Node devs to use the fastest possible configurations in their tests.

That PHP tes has curiously high stats compared to other full stack frameworks like larval, which rates much worse. Makes me wonder how it’s so fast.

Not any better. The existing tests were written by me and use the CommandBox docker container whichs runs a pure Java undertow web server which is blazing fast. Adding Nginx would literally just add a network hop to each request for no reason. These tests don’t hit any sort of static assets, so there’s no benefit to that.

On this topic, I just made a post with a larger comparison over on the Ortus Community:


I am curious why you didn’t include, PHP, and the possible exclusion of worker_threads for the Node.js benchmark. Without those, it looks like you’re … ahem … preaching to the choir. :innocent:

I did include PHP Laravel. I didn’t include .NET because I couldn’t figure out what filters would give the equivalent comparisons. I literally spent about an hour poking at the filters to try and find the best list. Feel free to create a filter of your own and post about it :slight_smile:

Actually I’m preaching to the preachers. Now you have a sermon outline the next time your manager wants to know why you’re not using <insert cool sounding language here>.

1 Like

Fortunately I’m a sole proprietor and none of my clients are that tech savvy!

1 Like

I just reread this and now I realize I was incorrect in assuming that Apache2 was the web server for the test, simply because that’s what I use. I didn’t imagine anything else because I also use cPanel, which makes managing all my websites so much easier, and cPanel of course requires a web server. I also didn’t know that running Lucee in the manner you did was an option, which makes me wonder how you manage multiple websites that way.

So now I’m wondering how Lucee performance fares when running via Tomcat/Apache2.

And conversely, how Node fares when using it’s own built-in http server (and worker_threads). Since the tests can be submitted by anyone, it’s possible that test wasn’t under optimum conditions?

Before preaching to Node enthusiasts who will no doubt question the fairness of your testing methodology, best be prepared with the Devil’s Advocate. :wink: :smiling_imp:

You mean managing multiple websites within CommandBox? There’s a couple approaches. The first is to just start a server for each site, which is what I do for local dev. I don’t normally have more than 3 or 4 running at a time.

server start site1
server start site2
server start site3

Each server is a separate JVM process, with potentially different version os of Java/Adobe/Lucee and custom JVM args if I wish.

CommandBox also supports ModCFML, which allows me to start a single server (JVM process) and sit it behind Apache, Ngin, or IIS/BonCode and serve multiple web roots just like you would on the “traditional” Lucee/Tomcat installation.

In production however, I personally use Docker Swarm where each site is scaled out as a service running one or more docker containers-- each having a single JVM process inside of it.

That’s a good question. I don’t think there’s any benefit at all to having Apahe in the mix for a strict performance test. It’s just a reverse proxy that each request has to bounce through. As far as Tomcat, I would expect the overhead of the servlet to be very low in any case-- the majority of a CF request comes from the CF engine itself. CommandBox uses JBoss Undertow which powers WildFly and JBoss EAP and is known for being extremely lightweight and fast. I highly doubt Tomcat has anything on Undertow in the pure speed department.

Of course! When you do start preaching to them, you can use this as fodder as well :wink:

Okay, but then what’s your alternative to cPanel which elegantly handles such a massive amount of server config and maintenance chores?

That’s sort of a different concern. CommandBox is a CLI capable of spinning up servlet deployments. So it’s like a scriptable version of Tomcat, or Jetty. Generally servlet containers have little to do with the higher level concerns of provisioning servers and such.

Docker Swarm does speak to that a bit more, but it’s a totally different paradigm. (K8s would be a similar, albeit much more complex version of Swarm). For example, at Ortus we use Digital Ocean to run all our Lucee sites. A droplets are provisioned using DO’s web UI, but the 4 or 5 droplets we have hosting our Docker Swarm was a one-time setup. Deploying a new site is purely a matter of adding the stack (a docker compose file) to the swarm which defines the services which are comprised of containers running out on the swarm. It’s a different mindset than the cpanel sort of scenario, but all that happens at a higher level than the servlet container is concerned with. There’s no reason why someone couldn’t use cpanel to provision servers running Commandbox-- i.e. it’s not mutually exclusive.

When talking about cPanel… What I really, really, really miss in the CFML ecosystem are hosters that host cfml just like it’s done with PHP (with the same pricing). There are tons of hosters around that you just sFTP transfer your WordPress php files, the hoster serves you also a self managed database (usually MySql) with phpAdmin and cPanel for 15Eur/month. They do all the stuff you need like backups of DB or wwwroot files, domain managment, SSL management and much more. I’d love to have that possibility in the CFML world, so I can just upload a clients cfml application files(including .htaccess files), import the data to the database and give that away to a client, and I wouldn’t bother about anything else envolving that hosting stuff.

I have a VPS at Hostek, but they also do shared Lucee hosting for as little as $6.79/mth.

Yeah, thx,I know Hostek. What I was trying to say is, that you have thousands(and more) of hosters delivering classic php/wordpress all over the place. Every hoster I see delivers PHP driven sites, while the cfml community may have just a few (worldwide). Would be so great if I tell a client he wouldn’t need to switch his hoster just to serve CFML.

We should also mention viviotech.


I totally hear you guys on CF hosting. IMO that’s not a technology issues, it’s purely a demand issue. Most of my CF clients through Ortus host their own servers and are larger Corp or Gov shops with the means to do so. The rest just maintain their own servers on AWS or Digital Ocean. The sad thing is, there is just very little relative demand for people wanting to spin up cheap sites on CF in the wild. At least not compared to PHP, etc. A lot of the mainstream hosting companies (like Godaddy) back in the day who used to offer shared CF hosting got stuck on crazy old versions and the only ones who stayed current were the companies who settled into the CF space exclusively (or at least primarily)

I think this is where Docker can be a huge boon to CF devs looking to host anywhere. The Container is the new hosting point of re-use and when you wrap a CF app up in a docker container, you can now run it literally anywhere who supports Docker. Heck, you can even run CF on Heroku like this. As much as I’d love to see hosting companies have first class support of CF, I think the better question is how can our CF apps follow a model that makes it so they can run on any hosting company easily. If you’re on Lucee, an licensing is not an issue, you’re half way there!

But on the note of CF hosting, Ortus is cooking up some ideas for a CF cloud hosting platform. Stay tuned :slight_smile:


I use this stack for production :grin::heart:

1 Like