Re: Webcat run amuk
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 44531
interpreted = N
texte = On 10/29/02 10:47 PM, Andrew Simpson mashed the following keys :> Andrew enters from stage left, yells Buy a PC ... exits hurriedly. > Hehe No comment, our xserve did seriously worse on the speed test with Jaguar than it did before (but considering that now it's under load and having problems at the moment I didn't consider it a definitive speed test :) > on a more serious not however... > > We did have this problem when we simulated intence traffic on a page with a > search that would normally take 35-40/60's. > > If we hit it 16-20 times before the page completed and had 16-20 spawned > processes runing, the cpu would slowly creep up and hit the big 197%. Once > webcat gets like this i think it has a hard time over coming it and the > search results never get returned.Funny thing is, when it's running at 190%, it's really hardly noticeable from a user perspective. Sites still seem to be served. The machine seems plenty quick. I usually just see the Xserve's proc indicator going nutso. (AHAH! See there is a case for look of the pretty blinky lights on an Xserve!!) oh, and BTW Andrew, a fast woman is nice and all, but I'd take a hot lookin' moderately quick woman I that I can get along with one over an ugly shrieking skank (XP!??) any day :)I guess I'm just shallow that way ;> > > I think we have generally found that the engine is clever enough to restart > itself on bad code but not on good code underload. > > Maybe you have a few new searches somewhere that are getting a bit of > traffic and take a while to complete - or you could have a search on an > include that includes itself.... been there, done that. > > all in all thou it becomes hard to track down the error because as webcat > gets crazy - soo do the debug logs. > > I think we had this argument a while back when i said code shouldn't be able > to bring down the server and i was told i was wrong - apparently it should. Yeah, I would generally agree with you that it shouldn't. I can see how you could write perfectly legitimate webDNA with an infinite loop that would consume it, but in general I think that very few things should. ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list
. To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
On 10/29/02 10:47 PM, Andrew Simpson mashed the following keys :> Andrew enters from stage left, yells Buy a PC ... exits hurriedly. > Hehe No comment, our xserve did seriously worse on the speed test with Jaguar than it did before (but considering that now it's under load and having problems at the moment I didn't consider it a definitive speed test :) > on a more serious not however... > > We did have this problem when we simulated intence traffic on a page with a > search that would normally take 35-40/60's. > > If we hit it 16-20 times before the page completed and had 16-20 spawned > processes runing, the cpu would slowly creep up and hit the big 197%. Once > webcat gets like this i think it has a hard time over coming it and the > search results never get returned.Funny thing is, when it's running at 190%, it's really hardly noticeable from a user perspective. Sites still seem to be served. The machine seems plenty quick. I usually just see the Xserve's proc indicator going nutso. (AHAH! See there is a case for look of the pretty blinky lights on an Xserve!!) oh, and BTW Andrew, a fast woman is nice and all, but I'd take a hot lookin' moderately quick woman I that I can get along with one over an ugly shrieking skank (XP!??) any day :)I guess I'm just shallow that way ;> > > I think we have generally found that the engine is clever enough to restart > itself on bad code but not on good code underload. > > Maybe you have a few new searches somewhere that are getting a bit of > traffic and take a while to complete - or you could have a search on an > include that includes itself.... been there, done that. > > all in all thou it becomes hard to track down the error because as webcat > gets crazy - soo do the debug logs. > > I think we had this argument a while back when i said code shouldn't be able > to bring down the server and i was told i was wrong - apparently it should. Yeah, I would generally agree with you that it shouldn't. I can see how you could write perfectly legitimate webDNA with an infinite loop that would consume it, but in general I think that very few things should. ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Aaron Lynch
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Annoying character on writefile... (2004)
WebCat2b13MacPlugIn - [showif][search][/showif] (1997)
Separate SSL Server (1997)
date range (1998)
WebCatalog on G3 Macs? (1997)
WebCat2 - [format thousands] (1997)
Unix DB Permission Error (2002)
PC Authorize & Webmerchant (1998)
Memorial Day Weekend (2003)
RE: Purchased cart being overwritten (1997)
Re:2nd WebCatalog2 Feature Request (1996)
webcatalog [date] bug...not (1999)
Merchant and WebCat 3.0 (1998)
Error: Too many nested [xxx] contexts (1997)
WebCat for mass emailings (1997)
WebCat2: Items xx to xx shown, etc. (1997)
[WebDNA] cart stored as a session cookie (2008)
Nesting format tags (1997)
Error & Problem (1997)
Mozilla Firefox problem (2004)