FYI - I made a few changes to reactorBlog that speed the issues that Gary point out. The ratings table was not a good idea. First off, I don't need to know every rating in history. Secondly, I had a LOT of ratings (one with over 12,000 (musta been a bot)). Running aggregates across that is expensive.
I made some changes to reactorBlog to remove the ratings table and store the data in the entry table. MySQL people - can you let me know if my updates work for you too? I made the changes for mysql, but didn't test them. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes Sent: Sunday, March 05, 2006 10:01 PM To: [email protected] Subject: RE: [Reactor For CF] Performance of Reactor Gary, I've been fretting since you sent your initial message about the perceived speed of doughughes.net. You essentially said that, because the ColdFusion category came up slow that the Reactor framework must be slow. On the surface this makes sense. There's no secret that I use ReactorBlog. So, it seems, if you want to get an idea of how fast reactor is then you go to a site you know runs Reactor and see how fast it feels. I spent some time today testing parts of the framework to find out where the bottlenecks are. (I found some interesting ones - more on this later.) After I fixed a few problems I went back to a local copy of ReactorBlog and tested it, expecting to find it feeling much faster. Oddly, it didn't! Why ever not?! To track this down I turned on execution time reporting and was surprised to find one method being the problem getMatching() on the entryGatway. All other steps were at or less than 16ms. What was the problem with getMatching(). I opened it up and was amused to find that it's a custom, handwritten query! That's right; the slowness isn't even reactor's fault. The particular query does some date parsing (for grouping purposes) and returns a reasonably large amount of data from MSSQL. The resulting page is also nearly 90kb with images, css or scripts. Clearly the bottleneck is either in MSSQL, how the query was written or the transport between mssql and cf. The moral of the story? Don't judge a framework's speed based on an app on a server that you don't have access to. Run the code locally, break it down into little pieces and test atomic parts of it. Oh - one other thing: I found a really boneheaded mistake I made in the objectFactory. For quite a while now Reactor has been inspecting the database no matter what mode it was in. This means that all production apps running Reactor have really been running in development mode. Doh! I fixed that and committed. The framework seems much faster now. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Herman Sent: Thursday, March 02, 2006 3:49 PM To: [email protected] Subject: RE: [Reactor For CF] Performance of Reactor Doug, Just checked your site again, looks like the server reboot did speed things up a little bit - but I'm still seeing a slow down in the larger categories. I realize the code has not been tweaked for performance just yet, but I wanted to bring this up now since the performance lag we are seeing is quite large. Overhead is to be expected here - hopefully, this will decrease when you get closer to a final release! Thanks, Gary -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes Sent: Thursday, March 02, 2006 5:19 AM To: [email protected] Subject: RE: [Reactor For CF] Performance of Reactor My server is having disk errors. It just took 20 minutes to reboot it. I'm pretty sure this isn't a reactor issue. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Herman Sent: Thursday, March 02, 2006 2:26 AM To: [email protected] Subject: RE: [Reactor For CF] Performance of Reactor Hmmm, I just went to doughughes.net and clicked on the "Cold Fusion" category - it took quite a long time to load, 40 seconds. To be scientific, I tried this from 3 different computers running with 3 different DSL providers and the results were the same. I tried other categories as well; the small ones load at decent speeds, but the larger catgeories take a *long* time to load. Am I missing something here? Gary -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes Sent: Monday, February 27, 2006 2:12 PM To: [email protected] Subject: RE: [Reactor For CF] Performance of Reactor I'm using reactor on a number of sites and I'm not seeing speed problems. (See doughughes.net). I know others are seeing acceptable speed too. If you have reactor in the application scope are you sure it's actually running in production mode? If you had it in development mode and put it in the application scope, it wouldn't pick up changes to production mode unless you reloaded the application. You'll also see a nice speedup with trusted caches turned on. I'm not using them on doughughes.net. If you could dig into the reactor code and determine where the speed problems are, it would be most helpful. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cody Caughlan Sent: Monday, February 27, 2006 3:32 PM To: [email protected] Subject: [Reactor For CF] Performance of Reactor I am using the latest version of Reactor. I have 5 tables (User, Address, Company, Email and Phone) with many-to-many links between User and all of the others. For getting my feet wet purposes I have built a basic no frills page that takes the ID of a given User and display all of their profile information (their address, the company they work for, the company's address, etc). Using the GetTickCount() function and with Reactor in "production" mode and Debugging turned off in CF I the page takes on average 1.5 seconds to execute. Eventually we will be integrating Reactor with MachII, but this basic page is just that, a straight no framework page. I am concerned that with adding the MachII overheard the combo of MachII and Reactor might be a little overboard. For completeness sake I put the Reactor factory in Application scope with its init() so granted this wouldnt be done per-request, and that did seem to save a little bit of time. My question overall is is, how performant is Reactor and are people seeing acceptable production ready speeds with it? Are there any other tricks that can be used to speed up Reactor? I know that it uses lazy-loading and I gave it a couple of requests so that all Record / Gateways / Iterators objects were created, but still couldnt get it less than 1.5 seconds. We have this running on 2 servers (1 for IIS and 1 for MSSQL, both are very beefy, so its not a hardware issue). Previously when we were running MX6.1, basic MachII apps were running slowly. As soon as we upgraded to MX7, those same apps just FLEW (to us it seemed to be a night and day difference). I dont know what relevance this has to Reactor, but just our experiences. Thanks /Cody -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
