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:
Showing unopened cart (1997)
Discounts (1998)
SKU lookup (1997)
Mac v. NT (1998)
OSX Webcatalog Install (2001)
WebCommerce: Folder organization ? (1997)
Multiple prices (1997)
[WriteFile] problems (1997)
Surprise x and y post args (1998)
Tax Rate (2000)
Extra Text Fields (was Another question) (1997)
2.0 Info (1997)
Error: Too many nested [xxx] contexts (1997)
Showif probably dumb question (1997)
Shopping Cart Problem (1998)
Dummy Credit Card Number for debug? (1997)
Generating unique SKU from [cart] (1997)
Modulo function? (2000)
Last digit of Credit Card Stripped (1997)
[shownext] and descending order (1997)