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:
Is everybody getting all the posts? (2002)
too many nested tags ... (1997)
Re:PCS Customer submissions ? (1997)
Search returns all, not 20 (1997)
Images do not upload completely ... (2003)
WebDNA module - Automated database archiving (1997)
printing twice? and fix (1997)
Possible Bug in 2.0b15.acgi (1997)
SSL, WebSTAR, WebCatalog (1998)
Blank orders after update to 5.1 (2003)
ShowIf helper? (1998)
possible, WebCat2.0 and checkboxes-restated (1997)
Appendfile memory usage (redux) (2003)
Cant open pages generated by Webcat (2004)
WebDelivery downloads alias, not original ? (1997)
Sorting Round 2 plus (1998)
show all problem (1997)
For those of you not on the WebCatalog Beta... (1997)
writefile and texte (1997)
taxRate is fine but taxTotal isn't (1997)