i agree. one more thing i was told to check is to see if the db was indexed or not, and see if we can get back to storing them in the db. could it be that the client variable db not being indexed is what made it so slow? (i'm a very novice dba so if i sound dumb about it that's why) : )
At 01:16 PM 2/18/2002, you wrote: >i doubt i'll be a single voice on this, but i would highly encourage >investigating/optimizing your code, network configuration, or SQL >configuration as opposed to using the registry in place of a read/write >table. without knowing your hardware configuration, you might also consider >increasing the amount of physical memory and/or processing power. > >-----Original Message----- >From: pete ellefson [mailto:[EMAIL PROTECTED]] >Sent: Monday, February 18, 2002 1:11 PM >To: CF-Server >Subject: RE: NT error 232 & low performance > > >i've had a similar problem before, and maybe your solution. > >recently we re-built our servers, and moved them to a new co-lo facility >and the only things we changed was: CF 4.5 > 5... other than that the >same setup. separate machines. one for CF 5 one for SQL 7. > >after the move our page execution time was 5 seconds before the page began >to load; and after much testing we figured out that our client variables >was the main bottleneck. previously we were storing the client variables >in a database on the sql box. next we tried storing the variables as >cookies, and it instantly increased speed to lightning fast; but some of >our code caused errors this way... so next we switched it to store the >client variables in the registry. also very fast, and no errors... so we >figured it out... sort of... now the registry is growing at a couple megs a >day, so we just need to write a script to delete the old ones. > >check in the cf administrator under Server Settings : client variables to >see how your storing the client variables. > >this is funny because more than a year ago, we had un-intentionally left >the client variables in the registry (and weren't deleting old ones) and >after awhile we had a 70mb registry, and got registry full errors, so i >bumped the registry size up. then it filled up again... after a while it >was up to 130 mb, and we figured out what was happening, thus a re-install >of the OS and a fresh start. > >hope this helps. >[EMAIL PROTECTED] > > >At 03:15 PM 2/18/2002, you wrote: > > > The performance of the application is VERY bad: build time > > > for the pages is between 8 and 30 secs. Although there are > > > very many SQL queries executed (abt. 40 per page), this > > > seems not to be the problem, because cpu utilization of > > > the database server is very low. > > > >As a wagering man, I'd put my money on these queries. That's a lot of > >database interaction, and keep in mind that it takes time to move >recordsets > >back and forth over the wire. Do you need to execute all these queries per > >page? What happens to query execution times under load? > > > > > I know there are many threads covering this issue, but I > > > couldn't find a solution at all. Could changing to Apache > > > be a solution if this is a IIS related error? > > > >It's highly unlikely that this has anything to do with your web server. The > >reason that you're not likely to find a simple solution to this online is > >just that it usually doesn't have a simple solution - you're doing too much > >work in your application, and you might have to rethink some portions of > >your application. > > > >Dave Watts, CTO, Fig Leaf Software > >http://www.figleaf.com/ > >voice: (202) 797-5496 > >fax: (202) 797-5444 > > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com ------------------------------------------------------------------------------ To unsubscribe, send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body or visit the list page at www.houseoffusion.com
