Re: [WebDNA] WebDNA code validator

This WebDNA talk-list message is from

2011

It keeps the original formatting. numero = 107150
interpreted = N
texte = --0016362841fed8acad04a9392ec2Content-Type: text/plain; charset=ISO-8859-1I just looked through our databases and noticed several 2GB files:orders.db (59MB)orders.db-tmp (2GB)orders.db-tmp1 (2GB)orders.db-tmp2 (2GB)orders.db-tmp3 (2GB)orders.db-tmp4 (2GB)orders.db-tmp5 (2GB)orders.db-tmp6 (2GB)orders.db-tmp7 (2GB)orders.db-tmp8 (2GB)orders.db-tmp9 (2GB)I'm thinking that this may be the file rewriting you were referring to. Theoriginal orders.db is a reasonable size but all of the copies (all lastmodified in the last 2 days) are 2GB each.Any idea what I can do to stop this from happening?Thanks,Daniel Meola301-486-0901daniel@knifecenter.comOn Fri, Jul 29, 2011 at 1:56 PM, Daniel Meola wrote:> 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>>>>--0016362841fed8acad04a9392ec2Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableI just looked through our databases and noticed several 2GB files:

orders.db (59MB)

orders.db-tmp (2GB)

orders.=db-tmp1 (2GB)

orders.db-tmp2 (2GB)

orders.db-tmp3 (2GB)=

orders.db-tmp4 (2GB)

orders.db-tmp5 (2GB)

orders.d=b-tmp6 (2GB)

orders.db-tmp7 (2GB)

orders.db-tmp8 (2GB)<=/div>

orders.db-tmp9 (2GB)

I'm thinking th=at this may be the file rewriting you were referring to. The original order=s.db is a reasonable size but all of the copies (all last modified in the l=ast 2 days) are 2GB each.=A0

Any idea what I can do to stop this from happening?

Thanks,

Daniel Meola

301-486-0=901

daniel@knifecenter.com

<=br>

On Fri, Jul 29, 2011 at 1:56 PM, Daniel =Meola <danie=l@knifecenter.com> wrote:

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 datab=ase? (Our largest is 57MB)

Thanks,
=
Daniel Meola
=301-486-0901
daniel@knifecenter.com
<=br>

=On Fri, Jul 29, 2011 at 1:31 PM, <christophe.billiottet@web=dna.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 are subscribed= to
the mailing list <ta=lk@webdna.us>.
To unsubscribe, E-mail to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: suppo=rt@webdna.us

--0016362841fed8acad04a9392ec2-- Associated Messages, from the most recent to the oldest:

Re: [WebDNA] WebDNA code validator (Kenneth Grome 2011)
Re: [WebDNA] WebDNA code validator (christophe.billiottet@webdna.us 2011)
Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
Re: [WebDNA] WebDNA code validator (christophe.billiottet@webdna.us 2011)
Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
Re: [WebDNA] WebDNA code validator (Daniel Meola 2011)
Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
Re: [WebDNA] WebDNA code validator (Donovan Brooke 2011)
[WebDNA] WebDNA code validator (Daniel Meola 2011)

--0016362841fed8acad04a9392ec2Content-Type: text/plain; charset=ISO-8859-1I just looked through our databases and noticed several 2GB files:orders.db (59MB)orders.db-tmp (2GB)orders.db-tmp1 (2GB)orders.db-tmp2 (2GB)orders.db-tmp3 (2GB)orders.db-tmp4 (2GB)orders.db-tmp5 (2GB)orders.db-tmp6 (2GB)orders.db-tmp7 (2GB)orders.db-tmp8 (2GB)orders.db-tmp9 (2GB)I'm thinking that this may be the file rewriting you were referring to. Theoriginal orders.db is a reasonable size but all of the copies (all lastmodified in the last 2 days) are 2GB each.Any idea what I can do to stop this from happening?Thanks,Daniel Meola301-486-0901daniel@knifecenter.comOn Fri, Jul 29, 2011 at 1:56 PM, Daniel Meola wrote:> 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>>>>--0016362841fed8acad04a9392ec2Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: quoted-printableI just looked through our databases and noticed several 2GB files: