Re: [WebDNA] WebDNA code validator
This WebDNA talk-list message is from 2011
It keeps the original formatting.
numero = 107149
interpreted = N
texte = --0016e68ee46cb64ad604a938fe1e Content-Type: text/plain; charset=ISO-8859-1 It sounds like the multi-server option would take a lot of work to get set up properly. A few of the databases are written to frequently (orders and quanityt on hand)- this would probably be much simpler if we used SQL. Version 7 is also a long way off because of the deprecated commerce tags we are using. Our site search does search a lot of fields and may be the source of our problem. Site search certainly increases as traffic increases. " For instance, if you use [append] against a large database, it will rewrite the entire database to disk after each single [append]." What would be considered a large database? (Our largest is 57MB) Thanks, Daniel Meola 301-486-0901 daniel@knifecenter.com On Fri, Jul 29, 2011 at 1:31 PM,
wrote: > Hi Daniel! > > On Jul 29, 2011, at 13:49, Daniel Meola wrote: > > > Finally, I can only assume that at some point a single server can only > handle so much traffic. Perhaps we have reached that point. Has anyone > successfully set up load balancing across multiple WebDNA servers? > > > If you are in the situation where you write to databases, you can't (at > this time) sync multiple servers databases loaded in RAM, though we will > work on a solution in the future. If you just "read" a database, then yes, > you can run multiple servers with the same content. One solution could be to > to route the "read" requests to a round robin cluster of servers and route > the "write" requests to a single server, whose database content would be > regularely copied to the read-only boxes. Google is using something like > this. Another solution is to run several dedicated front-end web servers and > one dedicated WebDNA 7.0 FastCGI back-end server: this will work. > > However, carefully coded WebDNA website running on a high speed CPU with > lighttpd (faster, smaller footprint and faster FastCGI interface than > apache) and WebDNA 7.0 will handle a very high load without any problem > (faster than the same hardware with php + MySQL). Speed problems arise with > badly designed complex search commands, or if you write a lot to your disk. > For instance, if you use [append] against a large database, it will rewrite > the entire database to disk after each single [append]. > > - chris--------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --0016e68ee46cb64ad604a938fe1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It sounds like the multi-server option would take a lot of work to get= set up properly. A few of the databases are written to frequently (orders = and quanityt on hand)- this would probably be much simpler if we used SQL.= =A0
Version 7 is also a long way off because of the depreca= ted commerce tags we are using.
Our site search do= es search a lot of fields and may be the source of our problem. Site search= certainly increases as traffic increases.
"=A0For instance, if you use [append] against a large d= atabase, it will rewrite the entire database to disk after each single [app= end]."
What would be considered a large database? (= Our largest is 57MB)
Thanks,
Daniel Meola<= br>
On Fri, Jul 29, 2011 at 1:31 PM,
<christop= he.billiottet@webdna.us> wrote:
Hi Daniel!
On Jul 29, 2011, at 13:49, Daniel Meola wrote:
> Finally, I can only assume that at some point a single server can only= handle so much traffic. Perhaps we have reached that point. Has anyone suc= cessfully set up load balancing across multiple WebDNA servers?
If you are in the situation where you write to databases, you can'= ;t (at this time) sync multiple servers databases loaded in RAM, though we = will work on a solution in the future. If you just "read" a datab= ase, then yes, you can run multiple servers with the same content. One solu= tion could be to to route the "read" requests to a round robin cl= uster of servers and route the "write" requests to a single serve= r, whose database content would be regularely copied to the read-only boxes= . Google is using something like this. Another solution is to run several d= edicated front-end web servers and one dedicated WebDNA 7.0 FastCGI back-en= d server: this will work.
However, carefully coded WebDNA website running on a high speed CPU with li= ghttpd (faster, smaller footprint and faster FastCGI interface than apache)= and WebDNA 7.0 will handle a very high load without any problem (faster th= an the same hardware with php + MySQL). Speed problems arise with badly des= igned complex search commands, or if you write a lot to your disk. For inst= ance, if you use [append] against a large database, it will rewrite the ent= ire database to disk after each single [append].
- chris---------------------------------------------------------
--0016e68ee46cb64ad604a938fe1e Content-Type: text/plain; charset=ISO-8859-1 It sounds like the multi-server option would take a lot of work to get set up properly. A few of the databases are written to frequently (orders and quanityt on hand)- this would probably be much simpler if we used SQL. Version 7 is also a long way off because of the deprecated commerce tags we are using. Our site search does search a lot of fields and may be the source of our problem. Site search certainly increases as traffic increases. " For instance, if you use [append] against a large database, it will rewrite the entire database to disk after each single [append]." What would be considered a large database? (Our largest is 57MB) Thanks, Daniel Meola 301-486-0901 daniel@knifecenter.com On Fri, Jul 29, 2011 at 1:31 PM, wrote: > Hi Daniel! > > On Jul 29, 2011, at 13:49, Daniel Meola wrote: > > > Finally, I can only assume that at some point a single server can only > handle so much traffic. Perhaps we have reached that point. Has anyone > successfully set up load balancing across multiple WebDNA servers? > > > If you are in the situation where you write to databases, you can't (at > this time) sync multiple servers databases loaded in RAM, though we will > work on a solution in the future. If you just "read" a database, then yes, > you can run multiple servers with the same content. One solution could be to > to route the "read" requests to a round robin cluster of servers and route > the "write" requests to a single server, whose database content would be > regularely copied to the read-only boxes. Google is using something like > this. Another solution is to run several dedicated front-end web servers and > one dedicated WebDNA 7.0 FastCGI back-end server: this will work. > > However, carefully coded WebDNA website running on a high speed CPU with > lighttpd (faster, smaller footprint and faster FastCGI interface than > apache) and WebDNA 7.0 will handle a very high load without any problem > (faster than the same hardware with php + MySQL). Speed problems arise with > badly designed complex search commands, or if you write a lot to your disk. > For instance, if you use [append] against a large database, it will rewrite > the entire database to disk after each single [append]. > > - chris--------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > --0016e68ee46cb64ad604a938fe1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It sounds like the multi-server option would take a lot of work to get= set up properly. A few of the databases are written to frequently (orders = and quanityt on hand)- this would probably be much simpler if we used SQL.= =A0
Version 7 is also a long way off because of the depreca= ted commerce tags we are using.
Our site search do= es search a lot of fields and may be the source of our problem. Site search= certainly increases as traffic increases.
"=A0For instance, if you use [append] against a large d= atabase, it will rewrite the entire database to disk after each single [app= end]."
What would be considered a large database? (= Our largest is 57MB)
Thanks,
Daniel Meola<= br>
On Fri, Jul 29, 2011 at 1:31 PM,
<christop= he.billiottet@webdna.us> wrote:
Hi Daniel!
On Jul 29, 2011, at 13:49, Daniel Meola wrote:
> Finally, I can only assume that at some point a single server can only= handle so much traffic. Perhaps we have reached that point. Has anyone suc= cessfully set up load balancing across multiple WebDNA servers?
If you are in the situation where you write to databases, you can'= ;t (at this time) sync multiple servers databases loaded in RAM, though we = will work on a solution in the future. If you just "read" a datab= ase, then yes, you can run multiple servers with the same content. One solu= tion could be to to route the "read" requests to a round robin cl= uster of servers and route the "write" requests to a single serve= r, whose database content would be regularely copied to the read-only boxes= . Google is using something like this. Another solution is to run several d= edicated front-end web servers and one dedicated WebDNA 7.0 FastCGI back-en= d server: this will work.
However, carefully coded WebDNA website running on a high speed CPU with li= ghttpd (faster, smaller footprint and faster FastCGI interface than apache)= and WebDNA 7.0 will handle a very high load without any problem (faster th= an the same hardware with php + MySQL). Speed problems arise with badly des= igned complex search commands, or if you write a lot to your disk. For inst= ance, if you use [append] against a large database, it will rewrite the ent= ire database to disk after each single [append].
- chris---------------------------------------------------------
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:
autocommit problem (1998)
WC1.6 to WC2 date formatting -FIXED! (1997)
WebCat2 - Getting to the browser's username/password data (1997)
upgrading (1997)
WebCat2: multiple currency support (1997)
Upgrading old WebCat Database Files (1997)
Browser (agent) stats... (2004)
URGENT: NO BUG, woFIELDdata & FIELDword=ww (2002)
CyberCash problem in OS9/4.5 -> OSX/5.1 transition (2003)
still having search problem, please help :) (2004)
Error 11 (1996)
RE: WebCatalog2 for NT Beta Request (1997)
To use GREP to boldface text (2003)
Sku numbers (1997)
WebCat B13 Mac CGI -- Frames question (1997)
UPDATE PROBLEM (1997)
WebCatalog 402rc2 is now available (2001)
Server slowing down. (1997)
WebCat2b12 - nesting [tags] (1997)
WebCatalog2 Feature Feedback (1996)