Re: Freeze
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 47636
interpreted = N
texte = I had this problem way back when in version 3.? We had a database of over 20,000 items that we searched and then used the results of the [founditems] to do another search for each found item. This is the EXACT behavior we saw.- CharlesOn Monday, February 10, 2003, at 09:07 PM, Alex McCombie wrote:> On 2/10/03 8:57 PM, WJ Starck
wrote: > > My original post put be on a version earlier than 4.5.1. > > After a few hours of testing and monitoring I am fairly certain I > found the > cause... > > WebCat was just using lots o cycles because of what it was being asked > to > do. > > I dint think a tough search would stop the machine from doing anything > till > it was done, but then again Webcat is so damn fast it takes a lot to > get the > usage beyond anything but a blip anyway. > > Not on 4.5.1 > :-) > Alex > > >> Hmmm... >> >> You may be on to something. I've been noticing my 4.5.1 server has >> been >> unbelievably slow the last couple of weeks. Seems like that's about >> when I upgraded to 4.5.1 >> >> I wonder if another half gig or so of ram would help...? >> >>> >> -- >> >> Will Starck >> NovaDerm Skincare Science >> http://www.novaderm.com >> wjs@novaderm.com >> >> >> On Monday, February 10, 2003, at 07:50 PM, Kenneth Grome wrote: >> >>>> On 2/10/03 4:35 PM, John Hill wrote: >>>> >>>>> Could it be flushing large databases to disk after doing the >>>>> requisit number >>>>> of append/updates? That could tie up the machine. >>>> Yep good thought.... The problem is the regularity. >>> >>> I think it's the way the new version of webdna is programmed to >>> prevent db file corruption ... >>> >>> From my understanding (and please correct me if I'm wrong) webdna >>> 4.5.1 is the first version to automatically write out a temporary >>> copy >>> of whatever db it's writing to -- every time it writes to a db. Then >>> it deletes this temporary file after it has successfully written the >>> appropriate changes to the 'real' db file. >>> >>> Didn't SMSI say they implemented this behavior in order to protect >>> against data loss in the event of a crash? >>> >>> I think they made this the default behavior in 4.5.1 because some >>> people had been complaining about losing data and/or getting >>> corrupted >>> db files when a crash occurred at the same time that webdna was >>> writing to the file. Unfortunately what I do not know is if they >>> gave us an option to turn off this new feature, or if we have no >>> choice but to deal with the new problems it creates for us. >>> >>> My gut feeling is that the server may seem like it is taking a >>> break >>> (apparently refusing to respond for 5-15 seconds) every time a person >>> accesses a page that writes something to a db file. >>> >>> Is this possibly what's going on? >>> >>> I have noticed a slow response from my remote server as well, but >>> until now it never occurred to me that it was a problem with the >>> webdna software. After all, I'm thousands of miles away from my >>> server >>> and not always on a consistent or reliable connection. >>> >>> But if this has nothing to do with my connection and everything to do >>> with the way this version of webdna is coded, it would be very nice >>> to >>> learn that there's a preference that lets us shut off this >>> unnecessary temporary file writing. >>> >>> Personally I've never had any problems with webdna destroying a db >>> file upon a crash. And it would not create a problem for me anyways, >>> because long ago I created a template-based system that >>> automatically >>> backs up all my db files every hour or every day. >>> >>> Personally I would prefer the server to be as fast as possible, and >>> NEVER write or delete temporary db files upon every append or replace >>> or delete -- as it may be doing now ... >>> >>> >>> Sincerely, >>> Kenneth Grome > > > Alex J McCombie New World Media > Chief Information Officer Drawer 607 > 800/724.8973 Fair Haven, NY 13064 > Alex@NewWorldMedia.com http://OurClients.com > > Interface Designer WebDNA Programmer Database Designer > > > > ------------------------------------------------------------- > 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://webdna.smithmicro.com/ > ------------------------------------------------------------- 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://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
I had this problem way back when in version 3.? We had a database of over 20,000 items that we searched and then used the results of the [founditems] to do another search for each found item. This is the EXACT behavior we saw.- CharlesOn Monday, February 10, 2003, at 09:07 PM, Alex McCombie wrote:> On 2/10/03 8:57 PM, WJ Starck wrote: > > My original post put be on a version earlier than 4.5.1. > > After a few hours of testing and monitoring I am fairly certain I > found the > cause... > > WebCat was just using lots o cycles because of what it was being asked > to > do. > > I dint think a tough search would stop the machine from doing anything > till > it was done, but then again Webcat is so damn fast it takes a lot to > get the > usage beyond anything but a blip anyway. > > Not on 4.5.1 > :-) > Alex > > >> Hmmm... >> >> You may be on to something. I've been noticing my 4.5.1 server has >> been >> unbelievably slow the last couple of weeks. Seems like that's about >> when I upgraded to 4.5.1 >> >> I wonder if another half gig or so of ram would help...? >> >>> >> -- >> >> Will Starck >> NovaDerm Skincare Science >> http://www.novaderm.com >> wjs@novaderm.com >> >> >> On Monday, February 10, 2003, at 07:50 PM, Kenneth Grome wrote: >> >>>> On 2/10/03 4:35 PM, John Hill wrote: >>>> >>>>> Could it be flushing large databases to disk after doing the >>>>> requisit number >>>>> of append/updates? That could tie up the machine. >>>> Yep good thought.... The problem is the regularity. >>> >>> I think it's the way the new version of webdna is programmed to >>> prevent db file corruption ... >>> >>> From my understanding (and please correct me if I'm wrong) webdna >>> 4.5.1 is the first version to automatically write out a temporary >>> copy >>> of whatever db it's writing to -- every time it writes to a db. Then >>> it deletes this temporary file after it has successfully written the >>> appropriate changes to the 'real' db file. >>> >>> Didn't SMSI say they implemented this behavior in order to protect >>> against data loss in the event of a crash? >>> >>> I think they made this the default behavior in 4.5.1 because some >>> people had been complaining about losing data and/or getting >>> corrupted >>> db files when a crash occurred at the same time that webdna was >>> writing to the file. Unfortunately what I do not know is if they >>> gave us an option to turn off this new feature, or if we have no >>> choice but to deal with the new problems it creates for us. >>> >>> My gut feeling is that the server may seem like it is taking a >>> break >>> (apparently refusing to respond for 5-15 seconds) every time a person >>> accesses a page that writes something to a db file. >>> >>> Is this possibly what's going on? >>> >>> I have noticed a slow response from my remote server as well, but >>> until now it never occurred to me that it was a problem with the >>> webdna software. After all, I'm thousands of miles away from my >>> server >>> and not always on a consistent or reliable connection. >>> >>> But if this has nothing to do with my connection and everything to do >>> with the way this version of webdna is coded, it would be very nice >>> to >>> learn that there's a preference that lets us shut off this >>> unnecessary temporary file writing. >>> >>> Personally I've never had any problems with webdna destroying a db >>> file upon a crash. And it would not create a problem for me anyways, >>> because long ago I created a template-based system that >>> automatically >>> backs up all my db files every hour or every day. >>> >>> Personally I would prefer the server to be as fast as possible, and >>> NEVER write or delete temporary db files upon every append or replace >>> or delete -- as it may be doing now ... >>> >>> >>> Sincerely, >>> Kenneth Grome > > > Alex J McCombie New World Media > Chief Information Officer Drawer 607 > 800/724.8973 Fair Haven, NY 13064 > Alex@NewWorldMedia.com http://OurClients.com > > Interface Designer WebDNA Programmer Database Designer > > > > ------------------------------------------------------------- > 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://webdna.smithmicro.com/ > ------------------------------------------------------------- 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://webdna.smithmicro.com/
Charles Kline
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:
WebCommerce: Folder organization ? (1997)
WebCat2b12--[searchstring] bug (1997)
PCS Frames (1997)
Frames and WebCat (1997)
textarea input- nevermind (2002)
EIMS Problems (1997)
unsubscribe (1997)
Applescript in Webcatalog problem (1997)
Formulas.db + Users.db (1997)
WebMerchant & AuthorizeNet (2000)
Communigate+Webcat (2001)
Server crash (1997)
WebCat2: Items xx to xx shown, etc. (1997)
Navigator Parsing (1997)
Multiple prices (1997)
OT: Where to turn (2003)
MasterCounter and capitalization (1997)
Running 2 two WebCatalog.acgi's (1996)
[WebDNA] Graphite Forum (2009)
Weird Math and SV (1997)