[WebDNA] Server load

This WebDNA talk-list message is from

2008

It keeps the original formatting. numero = 100457
interpreted = N
texte = It's not the best time to open a thread like this since I'm leaving for a week's vacation later today and may not follow the (hopefully lively) discussion as closely as I'd like to. But this takes up so much of my brain's processor capacity at the moment I just can't let it rest. ;-)I've come to a point where I have to recode most of the WebDNA for my sites. Almost all my code is written to be compact - that is to require as little memory and as few databases as possible. That made a lot of sense when I originally opened the sites - back in the old days when disc space and RAM were expensive and WebDNA's cache could only hold a limited number of databases.Today it's processor capacity that is the limiting factor so I need to refocus my programming accordingly. The solution is of course to split large databases into several smaller ones and to precompile more of the content.The problem is that both these solutions increase the amount of raw data in the databases. At some point this will increase rather then reduce the server load and I have absolutely no idea where that point is.I know there is no definite answer to this but does anybody have any info about how far I should go? Even the vaguest suggestion would be higly apreciated.Here are a few of the issues I've run into the last few days:1. When is one big database better than several smaller ones? Example: I currently have one database of recommended CDs shared by several sites (all of them music related). Would it be better to have one smaller database for each site? It would reduce file size considerably but the *total* memory requirement would increase since much of the data from the old big database would be duplicated in several of the small ones.Obviously what is the best solution depends on how much of the content has to be duplicated but is there a way to guesstimate at which point one big database becomes better than a bunch of small ones?---2. When is [SEARCH] better than [LOOKUP]? Example: http://www.musicaviva.com/encyclopedia/display.html?phrase=waldzitherThis page gets data from two different databases via [LOOKUP] commands, one big (20+ MB) base for the main body and a much smaller one (1-2 MB) for the page title. It wouldn't be too difficult to add a page title field to the big database and get all the data from there with a [SEACRH] context but is that a good idea? (I need the small database for search results anyway but I don't *have* to use it on this diplay page).---3. Is it always better to set a variable than to recalculate value each time it's needed? Example: In a search results page like this:http://www.musicaviva.com/encyclopedia/list.html?alpha=fI need the index number for the last item three times. It's before the [FOUNDITEMS] contect so I have to calculate it by adding the number of entries listed to the startat value. Is it better to store this value as a variable or to calculate it three times?The "next-previous" navigation links on the same page raise a similar question. The code for it is rather long, includes quite a lot of calculations and appears both at the top and the bottom of the page. Should I store as a variable or include the code twice?---4. Is it a good idea to use variables for static text that occurs several times on the page? Back to the display page:Example: http://www.musicaviva.com/encyclopedia/display.html?phrase=waldzitherThe "back to top" links could easily be set as a variable. That would mean more calculation work for the server but also less data to handle. Will this increase or decrease the server load? (Unlike the two examples above, there is no WebDNA in the text snippet itself, just static html.)---5. Does anybody know of a good file serving service? I know this is a bit off topic but moving all the non-html/WebDNA files to another server would of course help. Not much but every little bit counts. Can anybody recommend such a pure file server service?What I need is: + A fast and - even more important - reliable server + Ftp access + Subdomain names pointing to the file server + File types: .gif, .jpg, .pdf, .mid, .kar, .mp3, .wav and .abc (.kar is "karaoke," just midi files with embedded lyrics, .abc is a text based music notation file format) + automatic redirects to main site for anybody trying to browse the file directories manuallyAt the moment I have no idea how much disc space or bandwidth I need.Frank Nordberghttp://www.musicaviva.comhttp://stores.ebay.com/Nordbergs-Music-Store?refid=store Associated Messages, from the most recent to the oldest:

Re: [WebDNA] Server load (Frank Nordberg 2008)
Re: [WebDNA] Server load (Paul Willis 2008)
Re: [WebDNA] Server load ("Brian B. Burton" 2008)
Re: [WebDNA] Server load (Frank Nordberg 2008)
Re: [WebDNA] Server load (Terry Wilson 2008)
Re: [WebDNA] Server load (Patrick Junkroski 2008)
Re: [WebDNA] Server load (Frank Nordberg 2008)
Re: [WebDNA] Server load ("Brian B. Burton" 2008)
[WebDNA] Server load (Frank Nordberg 2008)

It's not the best time to open a thread like this since I'm leaving for a week's vacation later today and may not follow the (hopefully lively) discussion as closely as I'd like to. But this takes up so much of my brain's processor capacity at the moment I just can't let it rest. ;-)I've come to a point where I have to recode most of the WebDNA for my sites. Almost all my code is written to be compact - that is to require as little memory and as few databases as possible. That made a lot of sense when I originally opened the sites - back in the old days when disc space and RAM were expensive and WebDNA's cache could only hold a limited number of databases.Today it's processor capacity that is the limiting factor so I need to refocus my programming accordingly. The solution is of course to split large databases into several smaller ones and to precompile more of the content.The problem is that both these solutions increase the amount of raw data in the databases. At some point this will increase rather then reduce the server load and I have absolutely no idea where that point is.I know there is no definite answer to this but does anybody have any info about how far I should go? Even the vaguest suggestion would be higly apreciated.Here are a few of the issues I've run into the last few days:1. When is one big database better than several smaller ones? Example: I currently have one database of recommended CDs shared by several sites (all of them music related). Would it be better to have one smaller database for each site? It would reduce file size considerably but the *total* memory requirement would increase since much of the data from the old big database would be duplicated in several of the small ones.Obviously what is the best solution depends on how much of the content has to be duplicated but is there a way to guesstimate at which point one big database becomes better than a bunch of small ones?---2. When is [search] better than [lookup]? Example: http://www.musicaviva.com/encyclopedia/display.html?phrase=waldzitherThis page gets data from two different databases via [lookup] commands, one big (20+ MB) base for the main body and a much smaller one (1-2 MB) for the page title. It wouldn't be too difficult to add a page title field to the big database and get all the data from there with a [SEACRH] context but is that a good idea? (I need the small database for search results anyway but I don't *have* to use it on this diplay page).---3. Is it always better to set a variable than to recalculate value each time it's needed? Example: In a search results page like this:http://www.musicaviva.com/encyclopedia/list.html?alpha=fI need the index number for the last item three times. It's before the [founditems] contect so I have to calculate it by adding the number of entries listed to the startat value. Is it better to store this value as a variable or to calculate it three times?The "next-previous" navigation links on the same page raise a similar question. The code for it is rather long, includes quite a lot of calculations and appears both at the top and the bottom of the page. Should I store as a variable or include the code twice?---4. Is it a good idea to use variables for static text that occurs several times on the page? Back to the display page:Example: http://www.musicaviva.com/encyclopedia/display.html?phrase=waldzitherThe "back to top" links could easily be set as a variable. That would mean more calculation work for the server but also less data to handle. Will this increase or decrease the server load? (Unlike the two examples above, there is no WebDNA in the text snippet itself, just static html.)---5. Does anybody know of a good file serving service? I know this is a bit off topic but moving all the non-html/WebDNA files to another server would of course help. Not much but every little bit counts. Can anybody recommend such a pure file server service?What I need is: + A fast and - even more important - reliable server + Ftp access + Subdomain names pointing to the file server + File types: .gif, .jpg, .pdf, .mid, .kar, .mp3, .wav and .abc (.kar is "karaoke," just midi files with embedded lyrics, .abc is a text based music notation file format) + automatic redirects to main site for anybody trying to browse the file directories manuallyAt the moment I have no idea how much disc space or bandwidth I need.Frank Nordberghttp://www.musicaviva.comhttp://stores.ebay.com/Nordbergs-Music-Store?refid=store Frank Nordberg

DOWNLOAD WEBDNA NOW!

[WebDNA] Server load

2008

Top Articles:

Related Readings: