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
= 301-486-0901
<= 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---------------------------------------------------------
This message is sent to you because you a= re subscribed to
the mailing list <talk@webdna.us&g= t;.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us

--0016e68ee46cb64ad604a938fe1e-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] WebDNA code validator (Kenneth Grome 2011)
  2. Re: [WebDNA] WebDNA code validator (christophe.billiottet@webdna.us 2011)
  3. Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
  4. Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
  5. Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
  6. Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
  7. Re: [WebDNA] WebDNA code validator (christophe.billiottet@webdna.us 2011)
  8. Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
  9. Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
  10. Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
  11. Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
  12. [WebDNA] WebDNA code validator (Daniel Meola 2011)
--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
= 301-486-0901
<= 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---------------------------------------------------------
This message is sent to you because you a= re subscribed to
the mailing list <talk@webdna.us&g= t;.
To unsubscribe, E-mail to: <talk= -leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us

--0016e68ee46cb64ad604a938fe1e-- Daniel Meola

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:

Please help (2004) [ot] ascii values for lf and cr (2001) Where's Cart Created ? (1997) spawn (1998) using showpage and showcart commands (1996) WebCatalog [FoundItems] Problem - AGAIN - (1997) Summing fields (1997) Which [index]? (1997) [tcpsend] (2001) HELP..Changing Price after adding to cart. (1999) Sorting (1998) Emailer (1997) RE: WebCatalog NT beta 18 now available (1997) This list needs a digest: rant, rave... (1997) 'does not contain' operator needed ... (1997) where to put code (1998) Bug or syntax error on my part? (1997) unable to launch acgi in WebCat (1997) ShipCosts database (1997) NetSplat and WebCat2 (1997)