Hi everyone, This thread, got me thinking about reviewing the “sysAdmin” sections of the documentation.
And adding in a “Recommended Settings” section.
Unfortunately “I” am not the person for coming up with what those settings should be.
I think there are two sub-sections that we should create / update throughout the existing sections of the documentation.
I can read up on all the Java command-line switches - but I simply don’t have the experience in tuning or the in-depth Lucee knowledge to truly understand what changing command line argument XXX means to the Lucee Server and the apps I create to run under it.
And;
What Lucee Admin options “should” we tweak / and to what?
I am really happy to make all the edits / PRs (do all the typing work) for the documentation - but need the technical expertise of others for what to write!
Lastly - if there is such a thing as “these are the settings you should probably go with”…
Would be sensible to make those the default settings of the Lucee Installers / xmls?
Lucee, java and CommandBox already come with good default settings in most cases. Telling people they need to blindly change anything probably isn’t a great idea-- most non-default settings are there to address specific issues and should be changed only if someone is actually experiencing that issue. So I’m leary of any page full of “JVM hacks” etc that people will just copy wholesale into their configs whether they need it or not.
I’m willing to bet the core issue in the thread you linked to will not wind up being some missed magic jvm arg or lucee setting, but will be code related, or a bug somewhere.
If it wasn’t clear - sorry.
I am not suggesting that we actually need to change anything.
But I do think it would prudent to review the defaults, publicly and ask the question;
what setting(s) do you always change after a a fresh install of Lucee.
So those items (if any) can be discussed.
“The following Lucee / Java settings might be useful for your Application / use-case.
Always test in a non-production environment, first.”
As an example : (amongst others) I would suggest;
Output / Whitespace Management : Change to “Simple”
I have never seem this cause a problem in any of my Applications and from a positive perspective, it has made notable “speed-up” improvements.
And from that - we could discuss;
That’s a shitty idea because of XXX /YYY
That’s a good idea
That’s a good idea with the following caveats…
And then;
Let’s include that in a documentation (sysAdmin / cookbook / whatever) “guide”.
Let’s include the following use-cases in the documentation where Whitespace Management already lives, to help users make a better choice.
My interest lies only in improving the documentation and I’m more than happy to do all the documentation changes that might come about from these discussions.
If finger quotes everyone finger quotes wants it made as a default in Lucee - that would just be a sensible extension of this work.
I like the idea as a sort of “tips and tricks” sort of thing. This setting is handy, etc. I would add this.bufferOutput=false which is probably the only lucee setting I always change on a site, but that’s really just something I do for making local dev easier so I can dump/abort.
Regarding CommandBox, if you want a sort of “these may be useful” sort of settings, here the slide deck from my “Securing and Tuning CommandBox Servers for Production” talk at Into The Box today which falls in that category.
Though nearly everything on the list is, “if you need this, here’s how to do it” not necessarily an “I recommend everyone use this” sort of thing. Feel free to borrow anything from there you want.
Something I’ve been contemplating for 6.0 is adding some pre-cooked settings profiles to the admin.
By default we ship lucee old school super compatible, which is great for getting started but you end up missing all the various tweaks available for better performance
My idea is a list of profiles, which can be opened and then selectively applied (think checkboxes)
@bdw429s , as @Gavin_Baumanis has explained, this is not only about solving issues that arise. It’s also about having as much information as possible about as many settings as possible. Having the knowledge gives you a measure of control. That is indispensable, especially in an integrated environment such as Lucee/CommandBox.
No one is looking for a magic bullet. What you call a core issue will always arise. That is 100% certain. As some wise person once said, it’s good to feed the hungry, even better to teach 'em to grow rice.
Like @Gavin_Baumanis , I think the documentation needs to be improved and to be beefed up.
By us.
All hands on deck, I’d say.
Perhaps, I’m jaded from years of experience, but that’s where I disagree a little We all know the joke about how people code by just copy/paste code from StackOverflow. I can’t count the number of times I’ve seen client setups that have a whole pile of JVM args or garbage collection settings that came from
a blog
a random consultant
Google
and no one knows what they do or exactly why they need them, but everyone is terrified to remove them because they assume it’s the magic sauce that keeps their servers running. I can also tell you from years of helping out with ColdBox, people’s eyes glaze over when presented with a ton of options and they want you to just tell what to set so they don’t have to think about it. These same people then go blindly copy any settings with the word “cache” in the name without regard for what the setting actually does or when it should be used and then are confused when it causes issues.
Anywhoo, I don’t want to rain on the creative parade, because I think there’s value in this idea. I guess I’m just cautioning that the framing shouldn’t (IMO) be “everyone should always use these settings”, but should be “these settings can be used to solve these problems”, or “these settings deal with security”, etc
