Re: [WebDNA] two ideas for running a cluster of WebDNA servers

This WebDNA talk-list message is from

2019


It keeps the original formatting.
numero = 114897
interpreted = N
texte = 2525 --000000000000ef19080594423419 Content-Type: text/plain; charset="UTF-8" My idea to avoid database sync/lag/delay and overhead was to have 3 servers... (1)one for content, one for images images.yourdomain.com directed to another server, and a third (3)for all your post.yourdomain.com for all your database needs... u r just creating more overhead reading and writing and moving your databases that would always have lag...if u doing huge/lots of images put them on another pipeline... webdna is very fast when I had my real estate site I was the only person updating every hour ripping through and merging/overwriting the whole MLS in less than a second and it was never off-line On Sat, Oct 5, 2019 at 8:41 AM wrote: > 1.- one front-end server that will redirect the requests through POST or > GET to a cluster of back-end servers. When the request is for writing, then > only one of the back-end servers is solicited (always the same), when is is > for reading, it could be any of the back-end servers. > > The "writing" server is the master, the others are slaves. Every 30 sec, > through rsync, the master is copied to a slave, and the WebDNA slave > reloads the databases in RAM. Meanwhile, the front-end server will direct > the reading requests to the other back-end servers, and this sequentially. > > Another idea would be the same front-end server with the same backend > servers, and instead of using rsync, the front end server would POST the > request to each one of the back-end servers: no more master and slave. > > Another idea would be to keep a log database of all the writing requests, > so, by reading this log file, all the "slaves" would get the same > information. Databases could even be rebuilt in case of necessity. > > I am sure there are other solutions. Any other idea? > > > - chris > > > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list talk@webdna.us > To unsubscribe, E-mail to: talk-leave@webdna.us > archives: http://www.webdna.us/page.dna?numero=55 > Bug Reporting: support@webdna.us > -- Brian Harrington Auto Glass Xpress 2655 Millersport Hwy. Suite 1063 Getzville, NY 14068 (716) 861-2029 www.Auto-Glass-Xpress.com --000000000000ef19080594423419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My idea to avoid=C2=A0database=C2=A0sync/lag/delay and ove= rhead was to have 3 servers... (1)one for content, one for images images.yourdomain.com directed to ano= ther server, and a third (3)for all your post.yourdomain.com for all your database needs... u r just creati= ng more overhead reading and writing and moving your databases=C2=A0that wo= uld always have lag...if u doing huge/lots of images put them on another pi= peline... webdna is very fast when I had my real estate site I was the only= person updating every hour ripping through and merging/overwriting the who= le MLS in less than a second and it was never off-line

On Sat, Oct 5, 2019 = at 8:41 AM <christoph= e.billiottet@webdna.us> wrote:
1.- one front-end server that will redirect the reque= sts through POST or GET to a cluster of back-end servers. When the request = is for writing, then only one of the back-end servers is solicited (always = the same), when is is for reading, it could be any of the back-end servers.=

The "writing" server is the master, the others are slaves. Every = 30 sec, through rsync, the master is copied to a slave, and the WebDNA slav= e reloads the databases in RAM. Meanwhile, the front-end server will direct= the reading requests to the other back-end servers, and this sequentially.=

Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave.

Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same = information. Databases could even be rebuilt in case of necessity.

I am sure there are other solutions. Any other idea?


- chris




---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list talk@w= ebdna.us
To unsubscribe, E-mail to: talk-leave@webdna.us
archives: http://www.webdna.us/page.dna?numero=3D55
Bug Reporting: suppo= rt@webdna.us


--
Bria= n Harrington
Auto Glass Xpress
2655 Millersport Hwy. Su= ite 1063
Getzville, NY 14068
(716) 861-2029
<= a href=3D"http://www.Auto-Glass-Xpress.com" target=3D"_blank">www.Auto-Glas= s-Xpress.com
--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --000000000000ef19080594423419-- . Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Donovan Brooke 2019)
  2. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (christophe.billiottet@webdna.us 2019)
  3. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Brian Harrington 2019)
  4. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Donovan Brooke 2019)
  5. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
  6. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
  7. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  8. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  9. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (christophe.billiottet@webdna.us 2019)
  10. RE: [WebDNA] two ideas for running a cluster of WebDNA servers ("Scott @ Itsula" 2019)
  11. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Stuart Tremain 2019)
  12. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Bob Minor 2019)
  13. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (Greg Nelson 2019)
  14. Re: [WebDNA] two ideas for running a cluster of WebDNA servers (WebDNA Solutions 2019)
  15. [WebDNA] two ideas for running a cluster of WebDNA servers (christophe.billiottet@webdna.us 2019)
2525 --000000000000ef19080594423419 Content-Type: text/plain; charset="UTF-8" My idea to avoid database sync/lag/delay and overhead was to have 3 servers... (1)one for content, one for images images.yourdomain.com directed to another server, and a third (3)for all your post.yourdomain.com for all your database needs... u r just creating more overhead reading and writing and moving your databases that would always have lag...if u doing huge/lots of images put them on another pipeline... webdna is very fast when I had my real estate site I was the only person updating every hour ripping through and merging/overwriting the whole MLS in less than a second and it was never off-line On Sat, Oct 5, 2019 at 8:41 AM wrote: > 1.- one front-end server that will redirect the requests through POST or > GET to a cluster of back-end servers. When the request is for writing, then > only one of the back-end servers is solicited (always the same), when is is > for reading, it could be any of the back-end servers. > > The "writing" server is the master, the others are slaves. Every 30 sec, > through rsync, the master is copied to a slave, and the WebDNA slave > reloads the databases in RAM. Meanwhile, the front-end server will direct > the reading requests to the other back-end servers, and this sequentially. > > Another idea would be the same front-end server with the same backend > servers, and instead of using rsync, the front end server would POST the > request to each one of the back-end servers: no more master and slave. > > Another idea would be to keep a log database of all the writing requests, > so, by reading this log file, all the "slaves" would get the same > information. Databases could even be rebuilt in case of necessity. > > I am sure there are other solutions. Any other idea? > > > - chris > > > > > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list talk@webdna.us > To unsubscribe, E-mail to: talk-leave@webdna.us > archives: http://www.webdna.us/page.dna?numero=55 > Bug Reporting: support@webdna.us > -- Brian Harrington Auto Glass Xpress 2655 Millersport Hwy. Suite 1063 Getzville, NY 14068 (716) 861-2029 www.Auto-Glass-Xpress.com --000000000000ef19080594423419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My idea to avoid=C2=A0database=C2=A0sync/lag/delay and ove= rhead was to have 3 servers... (1)one for content, one for images images.yourdomain.com directed to ano= ther server, and a third (3)for all your post.yourdomain.com for all your database needs... u r just creati= ng more overhead reading and writing and moving your databases=C2=A0that wo= uld always have lag...if u doing huge/lots of images put them on another pi= peline... webdna is very fast when I had my real estate site I was the only= person updating every hour ripping through and merging/overwriting the who= le MLS in less than a second and it was never off-line

On Sat, Oct 5, 2019 = at 8:41 AM <christoph= e.billiottet@webdna.us> wrote:
1.- one front-end server that will redirect the reque= sts through POST or GET to a cluster of back-end servers. When the request = is for writing, then only one of the back-end servers is solicited (always = the same), when is is for reading, it could be any of the back-end servers.=

The "writing" server is the master, the others are slaves. Every = 30 sec, through rsync, the master is copied to a slave, and the WebDNA slav= e reloads the databases in RAM. Meanwhile, the front-end server will direct= the reading requests to the other back-end servers, and this sequentially.=

Another idea would be the same front-end server with the same backend serve= rs, and instead of using rsync, the front end server would POST the request= to each one of the back-end servers: no more master and slave.

Another idea would be to keep a log database of all the writing requests, s= o, by reading this log file, all the "slaves" would get the same = information. Databases could even be rebuilt in case of necessity.

I am sure there are other solutions. Any other idea?


- chris




---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list talk@w= ebdna.us
To unsubscribe, E-mail to: talk-leave@webdna.us
archives: http://www.webdna.us/page.dna?numero=3D55
Bug Reporting: suppo= rt@webdna.us


--
Bria= n Harrington
Auto Glass Xpress
2655 Millersport Hwy. Su= ite 1063
Getzville, NY 14068
(716) 861-2029
<= a href=3D"http://www.Auto-Glass-Xpress.com" target=3D"_blank">www.Auto-Glas= s-Xpress.com
--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --000000000000ef19080594423419-- . Brian Harrington

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:

Stumpted Again (1997) Shared conversion under WebTen (1998) [WebDNA] checking for mixed case text (2009) Loops N Variables (1998) Crashes and prior posting (2006) Uh...can someone help me out with the b10? (1997) XML style (2001) pc (1997) [WebDNA] What version of linux (2009) attn: smitmicro - cart limitation (2002) WebCatalog and Webstar 3.02 (1998) WCS Newbie question (1997) Unique SKU Numbers (2000) W3c Validation (2004) Sort Order on a page search (1997) Nested tags count question (1997) Fun with dates (1997) Multiple prices (1997) formulas.db problem solved (1998) thankyou.tmpl (1997)