CF Summit Notes: ColdFusion is Racecar Fast, Patrick Quinn
October 17, 2014
ColdFusion is Racecar Fast, Patrick Quinn
(The slide deck for this talk was really great. I'd recommend downloading that as well; There were several slides pertaining to JVM arguments that I didn't have time to make note of, and some other very useful metrics as well.)
Indy 500 case study
http://adobe.ly/1r9hULg
How to tune / troubleshoot a CF server
- empirical
- approx 5 different data sets (logs, memory/thread profiling, monitoring tools)
PASS -- performance and stability stack
Not all bottlenecks / sources of trouble are equally worthy of your attention as others.
We don't just slap on generic settings when config'ing a server. Everything is empirical
Think of perf and stability as a "stack"
how the layers all interact is important
back in the day, database was easily the biggest bottleneck
still partially true, however JVM is probably tied for first
if you have a query that takes 1.5 seconds WITHOUT load, it's not going to scale
The Engine Room -- the JVM
Great default JVM settings - 64bit --
any 64 bit java server side thing, these settings will make things generally better (assuming you have the same amount of RAM, etc)
garbage collection - how java cleans up memory
this is where tuning comes in
don't want too many GC's
and don't want them to last a long time (because the "whole world stops" while GC is happening)
GCViewer -- great tool for reading the GC log
Java isn't a very good 64 bit env, it just doesn't do very well in 64 bit. That's what those above settings help to fix.
-Xms6144m -Xmx6144m
Should you set the start size the same as the maximum?
generally better to start the memory allocation with all the heap (set them the same) rather than let it grow as needed.
-Xss256k
set the size of a single thread
256 is a good number to start
-XX:MaxPermSize=640m
Perm Gen memory space
here we're setting a max of 640 mega bytes
(up until CF 10 there wasn't a "start size" for the Perm Gen)
-XX:PermSize=640m
Perm Gen is basically where CF stores classes
default GC in CF is the "parallel" GC
+UseConcMarkSweepGC
--- uses "concurrent mark sweep GC" instead. tends to be much better in CF
If you had to do ONE thing to the server to make it perform better, JVM tuning is that thing.
Virtually every time we come across a badly performing server, it's because the JVM settings are wrong.
Tuning thread pools --
after memory starvation, thread starvation is usually the next bottleneck
Important thread pools:
ColdFusion
Tomcat
Web server connector.
-- they all need to be "harmonized" so they perform well.
In generally, you want as MUCH concurrency as the machine can handle
maybe upwards of 300 or 400
Usually for a CF server, if you'er staring to queue requests outside of the request pool, that's when things start to go south and failures happen
TNT checklist
~55 point inspection to see why a server isn't behaving
from "ColdFusion TNT Services"
the way to tell if your settings are correct:
run load tests
See Fusion logging
Fusion Reactor logging
coldfusionsupport.net
webapper.com
(The slide deck for this talk was really great. I'd recommend downloading that as well; There were several slides pertaining to JVM arguments that I didn't have time to make note of, and some other very useful metrics as well.)
Indy 500 case study
http://adobe.ly/1r9hULg
How to tune / troubleshoot a CF server
- empirical
- approx 5 different data sets (logs, memory/thread profiling, monitoring tools)
PASS -- performance and stability stack
Not all bottlenecks / sources of trouble are equally worthy of your attention as others.
We don't just slap on generic settings when config'ing a server. Everything is empirical
Think of perf and stability as a "stack"
how the layers all interact is important
back in the day, database was easily the biggest bottleneck
still partially true, however JVM is probably tied for first
if you have a query that takes 1.5 seconds WITHOUT load, it's not going to scale
The Engine Room -- the JVM
Great default JVM settings - 64bit --
any 64 bit java server side thing, these settings will make things generally better (assuming you have the same amount of RAM, etc)
garbage collection - how java cleans up memory
this is where tuning comes in
don't want too many GC's
and don't want them to last a long time (because the "whole world stops" while GC is happening)
GCViewer -- great tool for reading the GC log
Java isn't a very good 64 bit env, it just doesn't do very well in 64 bit. That's what those above settings help to fix.
-Xms6144m -Xmx6144m
Should you set the start size the same as the maximum?
generally better to start the memory allocation with all the heap (set them the same) rather than let it grow as needed.
-Xss256k
set the size of a single thread
256 is a good number to start
-XX:MaxPermSize=640m
Perm Gen memory space
here we're setting a max of 640 mega bytes
(up until CF 10 there wasn't a "start size" for the Perm Gen)
-XX:PermSize=640m
Perm Gen is basically where CF stores classes
default GC in CF is the "parallel" GC
+UseConcMarkSweepGC
--- uses "concurrent mark sweep GC" instead. tends to be much better in CF
If you had to do ONE thing to the server to make it perform better, JVM tuning is that thing.
Virtually every time we come across a badly performing server, it's because the JVM settings are wrong.
Tuning thread pools --
after memory starvation, thread starvation is usually the next bottleneck
Important thread pools:
ColdFusion
Tomcat
Web server connector.
-- they all need to be "harmonized" so they perform well.
In generally, you want as MUCH concurrency as the machine can handle
maybe upwards of 300 or 400
Usually for a CF server, if you'er staring to queue requests outside of the request pool, that's when things start to go south and failures happen
TNT checklist
~55 point inspection to see why a server isn't behaving
from "ColdFusion TNT Services"
the way to tell if your settings are correct:
run load tests
See Fusion logging
Fusion Reactor logging
coldfusionsupport.net
webapper.com