Is Coldfusion REALLY multi threaded?

Stephen Richards wrote: > > We have 24 connections at the moment, as reported by the database.  (can't > use netstat because the CF server is running on the same machine as the > database, so it's a unix socket rather than port 5423. And how many of them are idle? In the mean time you might want to get somebody to look at that query, since 2 minutes is rather long. Jochem

It might not Be CF thats causing the problem, its most likley the DB thats escalating the Lock to a full table lock and thus preventing other users from running the queries until the table is free. Also try moving the DB onto another server, as we had a simular problem, with ingres and moving the CF app to a new server solved the problem. Jason Lees Systems Developer National Express Coaches Ltd. > Stephen Richards wrote: > > > > We have 24 connections at the moment, as reported by the database. (can't ----- Excess quoted text cut - see Original Post for more ----- how do I tell which ones are active? Yep, I agree with you about the query, and we're taking action on that, but it still raises the point that CF is unresponsive while a query is executing, and I am sure it is not supposed to be.  And the more  users log on, the worse it is going to become. ----------------------------- Stephen Richards 020 7903 3226 ------------------------------

Jas > It might not Be CF thats causing the problem, its most likley the DB thats > escalating the Lock to a full table lock and thus preventing other users > from running the queries until the table is free. Pretty much the only way to get a full table lock in PostgreSQL is to use a LOCK TABLE statement for PostgreSQL uses MVCC (a.k.a. better than row locking). Quite unlikely. > Also try moving the DB onto another server, as we had a simular problem, > with ingres and moving the CF app to a new server solved the problem. I am more thinking of a unixODBC issue (admittedly, I never was a fan of it). If you have plans to move to CF MX you might want to test if the concurrency is better with JDBC. Jochem

...with regards to the long query...we have an app that has several queries that run quite long, a couple in the 3 or 4 minute range.  These do not bring my CF server to a halt at all.  We average  almost 200  users per hour on busy days on this box.  Have a look at all your CFAdmin settings.  You may need to raise the 'limit simultaneous requests'.  We have it set to 40 for a four proc machine.  I have found through research and experience that if your app is very DB intense, raising this helps.  Also look at lowering the 'restart at x unresponsive requests'  We have it set at 5.  Also make sure you have 'timeout requests after x seconds' checked and set reasonably.   note that my experiences are with winblows boxen.  on Linux boxen, this may very. Doug ----- Excess quoted text cut - see Original Post for more -----

Hi Stephen, 40 is an awfully high setting for Limit Simultaneous Requests, we typically recommend you set that to 3-7 * per CPU, with 7 being on the high side. Regards, Christine Lawson Macromedia How your's works is how I would have expected. At the moment , limit simultaneous requests is not ticked - perhaps I should and set it to 40.  I'll try it and let you know. ----------------------------- Stephen Richards 020 7903 3226 ------------------------------ > ..with regards to the long query...we have an app that has several queries that run quite long, a couple in the 3 or 4 minute range.  These do not bring my CF server to a halt at all.  We average  almost 200  users per hour on busy days on this box.  Have a look at all your CFAdmin settings.  You may need to raise the 'limit simultaneous requests'.  We have it set to 40 for a four proc machine.  I have found through research and experience that if your app is very DB intense, raising this helps.  Also look at lowering the 'restart at x unresponsive requests'  We have it set at 5.  Also make sure you have 'timeout requests after x seconds' checked and set reasonably. > > note that my experiences are with winblows boxen.  on Linux boxen, this may very. ----- Excess quoted text cut - see Original Post for more -----

> At the moment, limit simultaneous requests is not ticked - > perhaps I should and set it to 40. I'll try it and let > you know. Setting it to forty would probably not be an especially good idea - that's an extremely high value. CF is designed to take advantage of queuing requests - some number get simultaneously processed and the rest go into a queue, and are serviced when free threads are available for them. This is supposed to be faster than simply processing all the requests at once (at least in Windows) and it's been my experience that it is, in fact, faster. As Christine Lawson noted, the recommended number is somewhere around 3-7 threads per processor. I'd add the caveat that to find the optimal number, load testing is required, and that you can see significant performance differences between the optimal number and the others. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444

Fully agree with you there Dave, like yourselves at Fig Leaf we are often involved in load-testing big web apps and that setting should be nowhere near 40 unless this is 6 processor box. You are totally right the actual number per processor is determined by the results of controlled and monitored load testing. Kind Regards - Mike Brunt, CTO Webapper Blog http://www.webapper.net Web site http://www.webapper.com Downey CA Office 562.243.6255 AIM - webappermb Web Application Specialists > At the moment, limit simultaneous requests is not ticked - > perhaps I should and set it to 40. I'll try it and let > you know. Setting it to forty would probably not be an especially good idea - that's an extremely high value. CF is designed to take advantage of queuing requests - some number get simultaneously processed and the rest go into a queue, and are serviced when free threads are available for them. This is supposed to be faster than simply processing all the requests at once (at least in Windows) and it's been my experience that it is, in fact, faster. As Christine Lawson noted, the recommended number is somewhere around 3-7 threads per processor. I'd add the caveat that to find the optimal number, load testing is required, and that you can see significant performance differences between the optimal number and the others. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444

Checking the Limit Simultaneous Requsts box, and setting it to 10 certainly has no effect.  One connection doing the query, everyone else just stuck. Interestingly, they make the connection to the database (I can see them attempting to log in, which they do as a different user), but they get no response from the login script until the query has finished. It's sounding more and more like an ODBC issue ----------------------------- Stephen Richards 020 7903 3226 ------------------------------ ----- Excess quoted text cut - see Original Post for more -----