Re: 'page impression' techniques for banner ads
This WebDNA talk-list message is from 1999
It keeps the original formatting.
numero = 22204
interpreted = N
texte = >How does closedatabase and commit database affect speed? If a server crashes >and use the #1 technique then I'll lose a lot of the data. So if I add a >commitdatabase call would that be the same as going to the disk like option >2?This is a good question. I've always wondered ...Which is faster, committing a database to disk every time or appending a character to a separate text file every time? I'll bet it has to do with the size of the db compared to the size of the file, but I would love to hear from PCS on this one too ... :)Since writing to a separate file auto-commits (if I may use that term in this situation) the value as it is written to that file, using option #2 would never require any special effort to commit the most current values to disk.Still, #2 would seem to be slower than adding a commitdatabase tag to the #1 snippet. But of course, there's really no need to commit the db after *every* page impression when using #1 either. After all, we are talking about 'page impressions' here -- data that is not generally considered to be extremely critical in the grand scheme of things.I recognize the need to commit the database once in a while, but there's another alternative to committing it to disk after every [replace]:By using option #1, combined with an entry in the triggers.db that commits the db to disk once an hour, webcat would be as fast as option #1 nearly all the time -- except for that fraction of a second once an hour when it commits the db to disk automatically. This technique would keep you from losing more than an hour's worth of page impressions, and you still have the full speed of option #1 ... :)Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Associated Messages, from the most recent to the oldest:
>How does closedatabase and commit database affect speed? If a server crashes >and use the #1 technique then I'll lose a lot of the data. So if I add a >commitdatabase call would that be the same as going to the disk like option >2?This is a good question. I've always wondered ...Which is faster, committing a database to disk every time or appending a character to a separate text file every time? I'll bet it has to do with the size of the db compared to the size of the file, but I would love to hear from PCS on this one too ... :)Since writing to a separate file auto-commits (if I may use that term in this situation) the value as it is written to that file, using option #2 would never require any special effort to commit the most current values to disk.Still, #2 would seem to be slower than adding a commitdatabase tag to the #1 snippet. But of course, there's really no need to commit the db after *every* page impression when using #1 either. After all, we are talking about 'page impressions' here -- data that is not generally considered to be extremely critical in the grand scheme of things.I recognize the need to commit the database once in a while, but there's another alternative to committing it to disk after every
[replace]:By using option #1, combined with an entry in the
triggers.db that commits the db to disk once an hour, webcat would be as fast as option #1 nearly all the time -- except for that fraction of a second once an hour when it commits the db to disk automatically. This technique would keep you from losing more than an hour's worth of page impressions, and you still have the full speed of option #1 ... :)Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Kenneth Grome
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:
2.0 Info (1997)
RAM variables (1997)
Banners (1997)
Apple event reply error (-1) (1997)
WebCat editing, SiteGuard & SiteEdit (1997)
Web Catalog vs. ICAT (1997)
NT considerations (1997)
Memory leak with text variables (1998)
redirect from the errorsMessages.db entry (1997)
Upgrading old WebCat Database Files (1997)
Relative URL quirk (1999)
Proper file locations (1997)
Using WC for Bulk Emailings (1997)
redirect within the ErrorMessages.db (2003)
What am I missing (1997)
price carry over (1997)
Error: Too many nested [xxx] contexts (1997)
ListFields and [name] (1997)
formatting search results (1999)
unusual search problem (1998)