Fastest Hardware for ColdFusion 9?

We are looking to speed up our application layer as much as possible. We've pumped the DB up substantially and had great results. I realize there are network, load balancer, memcache, etc and other ways than the hardware to have impact, but we want to buy whatever will give us some gain. Unfortunately, we didn't notice with a dual quad core server a ton of impact in the past and didn't seem to be able to get the full utilization, so we just stayed with multiple servers instead of fewer, beefier servers. Will 64 bit and many cores be the best for CF 9? Or less cores at higher clock? Does more memory help much? How about SSD hard drives for local source code?  I wouldn't expect that, but somebody seemed to suggest that somewhere. Does CF Enterprise make a big difference? Should we change the JVM to a faster one? What would that be? Thanks!

> Unfortunately, we didn't notice with a dual quad core server a ton of impact in the past and didn't seem to be able to get the full > utilization, so we just stayed with multiple servers instead of fewer, beefier servers. > > Will 64 bit and many cores be the best for CF 9? Or less cores at higher clock? > > Does more memory help much? I would definitely recommend 64-bit. Not necessarily for reasons of pure performance (response time & throughput) but because you'll be able to use memory better, and caching things in memory is one of the ways you can significantly improve application performance. As far as cores vs clock speed, this will be very application-dependent. In short, it depends on what your application does and how it does it. CF is multithreaded, so more cores is better than fewer cores, all other things being equal. > How about SSD hard drives for local source code?  I wouldn't expect that, but somebody seemed to suggest that somewhere. Unless your application does a lot of disk reads/writes (such as file uploads/downloads) this won't make much of a difference at all. Compiled CF files are cached in memory. > Does CF Enterprise make a big difference? Not unless you're using a feature specific to Enterprise. There are a bunch of features in Enterprise that either don't exist in Standard, or are "rate-limited" in Standard. PDF generation, for example, exists in both but performs significantly better in Enterprise. > Should we change the JVM to a faster one? What would that be? You should use the latest supported JVM for your version of CF, generally. That usually won't provide a speed increase, but will fix specific bugs in earlier JVMs. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite

As Dave said - 64bit will give you the biggest boost.  Mainly because you can setup massive memory allocations for the JVM.  Our servers each have 8Gb of memory with 4Gb setup for the JVM. More cores the better is the mantra, but we run 4 and 8 core servers and really don't see much different between the two in performance. I'd stick with SCSI drives if you need a lot of read/write access. And yes certain JVM upgrades can boost the speed mainly because of the bugs in earlier versions cause object creation to be very slow.   How much load is your application seeing?  Hard configuration and scale will be affected by your applications load. Wil Genovese One man with courage makes a majority. -Andrew Jackson A fine is a tax for doing wrong. A tax is a fine for doing well. On Mar 12, 2010, at 11:25 AM, John Foster wrote: ----- Excess quoted text cut - see Original Post for more -----

Hardware is important, but tuning is going to be more important.  You can throw 6 GB of ram at your application on a 64-bit JVM, but unless you tune your JVM and make changes to your application to use that memory, you won't see a dramatic increase in performance. Invest in profiling tools such as SeeFusion or FusionReactor to see where your performance bottlenecks are. If it is a database-heavy application, you may need to look at the execution plans of your queries and tune indexes. If you are running on Windows, set up a PerfMon session while load testing your application and see where your spikes are. CPU? Disk Access? Are you paging out to disk a lot? Talk to a company that does JVM tuning. There are some relatively simple things, like adjusting the different types of memory space and some much more esoteric things you can do like changing to a different garbage collector. There are also differences in speed between different CF versions and engines. One area that Railo beat the pants off of CF8 in was Object creation. If you are using an ORM that makes big arrays of objects for every query, that can be a definite bottleneck. CF9, however, made a lot of gains in the area of object creation performance.  CF9 and Railo both have support for ehCache as a caching provider now as well, which you can take advantage of in your code. There is also a performance difference between using Lists and Arrays when dealing with large sets of data. Bottom line, I'd say, is buy good hardware. Get testing tools like SeeFusion or FusionReactor and then a load testing tool like Selenium. Start profiling your apps to see where the slow parts are, then concentrate on those and get advice that is more specific to the issue *your* app is having as they will almost certainly be different than the issues that *my* app might be having. Cheers, Judah ----- Excess quoted text cut - see Original Post for more -----

We normally see about 12 requests / machine / sec during peak load.  I agree that 64 bit should help by making it possible to use more RAM. We're currently running 32bit with 1.25 GB allocated to the JVM and often come within 10 - 15% of the available JVM RAM on single machines for short periods of time.   Do you find that you are under-utilizing the CPU in the 8 core machines? Any suggestions for particular JVM upgrades that have helped you in the past or do you think upgrades / config tweaks are very application specific? ----- Excess quoted text cut - see Original Post for more -----

I have found it's really difficult to make a significant dent in 8 cores with a single use machine of any sort... (especially if they have adequate L2 cache - which incidentally is often more important than speed on a processor). It always seems underutilized unless it is a DB server servicing many other servers or a VMWare server sliced into a bunch of machines. There are plenty of other bottlenecks that tend to  pop up before the procs are really ALL in danger of pegging. The only acception we have seen on a single use machine is a fancy financial calculator running millions of calculations in a short period of time.   Mark A. Kruger, MCSE, CFG (402) 408-3733 ext 105 www.cfwebtools.com www.coldfusionmuse.com www.necfug.com We normally see about 12 requests / machine / sec during peak load.  I agree that 64 bit should help by making it possible to use more RAM. We're currently running 32bit with 1.25 GB allocated to the JVM and often come within 10 - 15% of the available JVM RAM on single machines for short periods of time.   Do you find that you are under-utilizing the CPU in the 8 core machines? Any suggestions for particular JVM upgrades that have helped you in the past or do you think upgrades / config tweaks are very application specific? ----- Excess quoted text cut - see Original Post for more -----

Depending on how much cash you want to part with, look at a 64 node Apple X-Serve system. I experimented with this when I worked for a biotech firm - they were using it for genomics and proteomics research. This thing was scary fast - and the load it could handle was astounding. http://www.apple.com/science/solutions/workgroupcluster.html regards, larry -- Larry C. Lyons web: http://www.lyonsmorris.com/lyons LinkedIn: http://www.linkedin.com/in/larryclyons -- The real problem is not whether machines think but whether men do. - B. F. Skinner - ----- Excess quoted text cut - see Original Post for more ----- > > > Thanks!

So I'm going to have to stick with 32 bit machines for a bit longer while we find alternatives for some com's we're using that don't work on a 64 bit platform. From my research It appears that request speed is directly correlated to CPU clock, not number of cores, cache, or bus speed.   Here are the average page load times from 3 different machines: 2x single core opteron 246 (2Ghz / core):  251ms 2x Dual core Xeon 5160 (3Ghz / core):  196ms 2x Quad core Xeon 5540 (2.53Ghz / core):  261ms We're running database servers on similar Xeon 5540 machines and the SQL performance on those boxes if far better that what we would get with the Opteron's or Xeon 5160's. Does anyone know why requests on the older generation xeon 5160 would be 20% faster than the current generation 5540?  Is the speed of a ColdFusion app purely based on clock speed in anyone elses experience? Thx, John

More cores doesn't mean "faster" it means more processing ability. In your example you compared a faster (3Ghz) Dual Core to a slower (2.53Ghz) Quad Core. In Practical Theory, the Quad Core can handle more requests per second than the Dual Core, but not twice as many requests... There is a factor of diminishing returns as you add more cores. =] ----- Excess quoted text cut - see Original Post for more -----

Sure, but the quad core is handling the same number of requests and processing them slower than the dual core.  On top of that the quad core machine's bus is more than twice as fast (533Mhz vs 1333Mhz) which I assumed may have made up for the slower clock speed. ----- Excess quoted text cut - see Original Post for more -----

So I'm going to have to stick with 32 bit machines for a bit longer while we find alternatives for some com's we're using that don't work on a 64 bit platform. From my research It appears that request speed is directly correlated to CPU clock, not number of cores, cache, or bus speed.   Here are the average page load times from 3 different machines: 2x single core opteron 246 (2Ghz / core):  251ms 2x Dual core Xeon 5160 (3Ghz / core):  196ms 2x Quad core Xeon 5540 (2.53Ghz / core):  261ms We're running database servers on similar Xeon 5540 machines and the SQL performance on those boxes if far better that what we would get with the Opteron's or Xeon 5160's. Does anyone know why requests run on the older generation xeon 5160 would be 20% faster than the current generation 5540?  Is the speed of a ColdFusion app purely based on clock speed in anyone elses experience? Thx, John