Maybe this is the answer. I started in console mode and got this message immediately:
Mar 24, 2012 5:09:28 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performanc
e in production environments was not found on the java.library.path: C:\ColdFusi
am Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Commo
n Files\Microsoft Shared\Windows Live;C:\ColdFusion9\verity\k2\_nti40\bin;C:\Win
erShell\v1.0\;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Pro
gram Files\WIDCOMM\Bluetooth Software\;C:\Program Files\WIDCOMM\Bluetooth Softwa
re\syswow64;C:\Program Files (x86)\Common Files\Ulead Systems\MPEG;C:\Program Fi
les (x86)\Microsoft SQL Server\90\Tools\binn\;C:\Program Files (x86)\EasyFrom;C:
\Program Files\MySQL\MySQL Server 5.1\bin;C:\Program Files (x86)\TortoiseSVN\bin
;C:\Program Files\TortoiseSVN\bin;c:\OpenSSL\bin\;C:\Program Files (x86)\Windows
Live\Shared;C:\Program Files (x86)\Common Files\HP\Digital Imaging\bin;C:\Progr
am Files (x86)\HP\Digital Imaging\bin\;C:\Program Files (x86)\HP\Digital Imaging
\bin\Qt\Qt 4.3.3;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files (x8
6)\PostgreSQL\8.4\bin; c:\Windows\System32;C:\Program Files (x86)\OpenVPN\bin;c:
No, I can tell you that I explored that myself a couple of weeks ago, and added found and added the libraries necessary to make that go away. When I did, it made no difference in startup time or runtime for requests.
As for your problem, I would propose to counter Liam, who suggests (reasonably) that perhaps server monitoring could be getting in the way (the CF Admin Server Monitor, available only in Enterprise and Developer editions). While he suggests “monitoring” and “profiling” could be at issue, I would contend instead that “memory tracking” (the 3rd of the 3 buttons at the top) might instead be the issue. That frequently causes problems (for some, though not all), while “profiling” is less burdensome, and “monitoring” far less.
In fact, the beauty of having “start monitoring” enabled is that you can see what requests are running, how long, and you can get a “stack trace” to see what exactly is making a request take a long time. I’ve written more about the monitor (in a 4-part series of articles, starting here: http://www.carehart.org/articles/#2007_2) and about stack tracing (http://www.carehart.org/blog/client/index.cfm/2009/6/24/easier_thread_dumps), including presentations on both http://carehart.org/presentations/.
One other thing: if you go back to starting CF normally, rather than at the console, there will be the same log entries and more in the \cfusion\logs\start.log. Look there to see if there’s any explanation, such as outofmemory errors that may explain your slowness. There’s nothing that makes CF10 inherently slow, so there must be some explanation. You mentioned slowness in the CF Admin. What about in apps other than the admin? Also, what if you enabled the built-in web server and accessed CF using that, rather than via Apache? That may show a problem in the Apache/CF connector (not there should be one, but it may help you focus on the real source, if none of the above pans out).
Providing fast, remote, on-demand troubleshooting services for CF (and CFBuilder)
See also http://www.cf911.com for more on CF troubleshooting resources
Looks like it was my 64 bit Apache build causing an issue. I deployed using Tomcat internal web server and through JBoss 6.1.0 as a war. Both look good. I solved my issue by grabbing the latest stable 64 bit build of Apache 2.2 (2.2.22) from Apache Lounge:
Installed this build, ran the connector, and now everything looks good. For reference, I was using a custom build of 2.2.15 that caused problems.