Lucee and ColdFusion Performance Comparison


#1

I keep hearing about that Lucee is faster than ACF. Are there any details about in what aspects Lucee is faster than ACF.
Alternatively is there any performance benchmark tests which showcase that Lucee is faster engine then ACF. Searching on Google gives me these two URLs

https://luceeserver.atlassian.net/browse/LDEV-1541

but no other details about where Lucee is better? Some aspects that i know about is low memory footprint as Lucee has on demand services loading but apart from that are there any technical blogs or sample tests which have been bechmarked and shows that Lucee is better in terms of Performance.

Thanks,
Tim


#2

Not sure, but am i using the wrong forum here? I have seen people describing in posts but there has been no description or details about in what aspects Lucee is faster? I tried searching for some details with some sample code snippets but couldn’t find it out so far.

I think folks on this forum should have the conclusive details.

Thanks,
Tim


#3

Well what you are asking for might be quite difficult. As someone that HAS done “speed” comparisons in the past it used to be quite tough as making a like for like comparison is quite complex. Is it pre-warmed? What are ALL the settings? Are the settings similar? or not? Is the server the same? etc etc.

So it might be best to see how your application compares. Even if you had two cars racing down the same road, the wind could be making a big difference to one and not the other.

If someone tells you THEIR app is much faster in X , it doesn’t necessarily mean YOUR app will be faster.

I did loop tests for component creation many years ago and I got a lot of heat since that wasn’t a realistic test. So not sure what to tell you. Lucee “feels” faster, and uses less resources and it has a smaller install footprint and costs… well, less.

You can tweak lucee to have many other performance improvements but then this wouldn’t be fair in a like for like comparison


#4

I’ve talked a lot about Lucee being fast before but as Mark said, it’s always a little relative to what you’re doing. I’ve been maintaining open source projects like ColdBox MVC for years so I’ve done a lot of speed tests across engines in the past. I will say that Adobe has made a lot of improvements in performance in the last few releases which is nice. Here’s a quick list off the top of my head of things that have contributed to Lucee being “fast”. But with all apps, YMMV based on your code and your load.

  • Lucee was passing arrays by reference before it was cool in CFML (less memory)
  • Lucee doesn’t duplicate cfthread inputs which can be a sucker punch to ACF apps
  • Lucee is modular and OSGI based so you can literally have a 20MB jar that contains the entire Lucee engine meaning smaller footprint on memory and on disk
  • Lucee always stored variable as native datatypes (numbers, booleans, etc) and had less casting (Adobe 2018 FINALLY started doing this)
  • Performance is viewed as a “bug” by the core dev team. Any regression in performance between releases is immediately fixed.
  • Lucee has purposefully not copied some ACF feature like implicitly treating query columns as an array specifically due to performance concerns
  • Lucee initial member function implementation was several orders of magnitude faster than ACF’s when it came out
  • getMetaData( CFCINstance) used to be around 100 times slower in Adobe CF in the CF8/CF9 days
  • In addition to being modular, Lucee has less bloat in the core engine. There’s no Flex engine, no CFClient, no sharepoint integrations.
  • Lucee was less work and faster to upgrade for years before Adobe finally caught up with a one-click updater
  • Lucee has always started up faster then ACF
  • Lucee has a far more robust caching engine which gives your app more options for performance caching in Couchbase, etc.
  • Lucee and Railo before has done a lot of hardcore performance tweaking as part of the professional support Micha and Gert offer through Rasia which has resulted in features like externalizing strings, in-memory DBs for QofQ, better whitespace management, optimizing output=false in components, and more class file caching options than ACF.
  • Some methods of string comparisons used to be really crappy slow in ACF due to internal casting and try/catching errors. Railo never did that.
  • Adobe CF will limit the number of requests you can even execute, the number of PDFS you can generate, and the number of event gateways threads you can have at once unless you have CF Enterprise. Lucee has never had such limitations and can run more concurrent threads than a Standard ACF server.
  • Lucee is more developer friendly and faster to code with more helpful features like cfdump’s showing you what file/line they came from, additional params to BIFs like directoryCreate() to save code, more flexible debugging, first to have elvis, first to have closures, first to have abstract, first to have final, first to have FULL script in tags, first to have tags in script. Lucee has basically pushed core CFML ahead faster over the years than Adobe ever has.
  • Lucee has a faster release cycle which means you can play with a snapshot build of a fix the day after it’s coded, not months later once it’s too late to change.
  • If I needed to provide an emergency fix for Lucee, I could create my own build of the engine in about 60 seconds with a single Ant build which can be the difference between getting a project out the door or waiting 6 months for a fix.

So clearly, some of those issue aren’t as big of a deal in 2018 but all of them were historically something that make Lucee/Railo faster. And some of those items are more just part of the process of writing apps and getting them out the door and into production. All reasons Lucee is “faster” at getting my sites live.


#5

It is good to hear about CFML


#6

In addition to what Brad said, Lucee also has features like localmode=“modern” on functions or as a global setting in the admin. There are also some options in the admin to disable the scope searching that coldfusion requires. If you are optimizing code for Lucee, you can speed it up by eliminate a lot of redundant hash map operations. Because virtually everything we write in CFML is stored in a hash map or reads a hashmap operation, this adds up to making this kind of code 2 to 5 times faster.

It’s also possible to use Lucee in a way that will make it slower then Coldfusion Standard. Because Lucee defaults to allowing each domain to run as a separate context. If you have a lot of shared library code for multiple sites, this doesn’t make sense. I redesigned my app to run all of the sites in the same context. The issue was that Lucee would have to manage separate class compilations for each domain even for code that is identical between them. You’d only have this same behavior in Coldfusion Enterprise, which allows multiple contexts. For example, my core library was around 400 cfcomponent files at that time, and I had 100 sites. Lucee had to compile and track changes on at least 400 * 100 * the number of functions java classes. I think it was tens of thousands of java classes. After I merged the sites together, it was only 400 * the number of functions, which is in the thousands, and the server can start much faster. If you are unable to redesign around this, then you might see the startup time worse, and the server requiring additional memory.

Lucee and Coldfusion are both built off servlet technology, which has concurrency scaling limits compared to non-blocking technologies, so it’s not like Lucee will serve 1000 times more request per seconds, since the underlying Java can only do so much with threads. Lucee and Coldfusion can both run out of memory a bit too easy and crash. This forces developers to split up big operations into smaller chunks because we don’t have streaming ways to work with queries in the language. I’ve started writing Java extensions to get around this limitation so we can do queries more similar to how Java JDBC works. But even JDBC is a blocking technology, so you end up needing more threads with high cpu clocks to achieve greater performance in normal Java apps. Java scales really nice to higher number of CPUs, so Lucee and Coldfusion will both be getting faster now that we have more cpus in modern systems. It’s not getting any easier to put Lucee on a tiny virtual machine. I feed the JVM many gigabtes of memory and extensively use caching and reduce hashmap operations to get the best performance.

I’ve been using Lucee since 2012 for hundreds of web sites. Using Lucee goes beyond performance really. We can affect Lucee through bug reports or code modifications since it is open source and community-oriented. I have seen that Lucee is more focused on what developers want. Lucee is as fast as you want it to be since you can build in custom Java, or at least verify it is efficient under the hood by reading the code. We can’t be sure what Coldfusion is doing under the hood. Railo & Lucee have had a good track record of making new releases that keep your code working just fine. You can also run versions of Lucee much sooner then the official release to have new features faster, and these tend to be safe to use as well.