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 = 114879
interpreted = N
texte = 2507 > 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. Actually in this situation the WebDNA dbs on the slave servers must be flushed immediately BEFORE each rsync overwrites them. If this happens every 30 seconds it will effectively defeat one of the main advantages of WebDNA -- its typically superfast "read from RAM" performance -- because every updated db would have to be read into RAM agai every 30 seconds. > 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. I did something similar many years ago, but instead of frontend and backend servers each server was equally available via a sequential round-robin load distribution system. This eliminated the need to flush the dbs every time one server posted an update to another server, because they would all be posted to at virtually the same time (within a fraction of a second from each other given a fast enough network connection). But when the internet connection between the servers goes down it creates SERIOUS out-of-sync problems such as failure to login, failure to see the updates the visitors just made, etc. ... and this would absolutely require your next idea in order to rebuild the dbs correctly when necessary: > 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. A system like this would become very complex and error-prone in my opinion, thus unlikely worth the effort when non-WebDNA solutions are readily available and have been tested and proven in terms of reliability for many years already. > I am sure there are other solutions. Any other idea? WebDNA's design is ideal for use on a single frontend server. To try and turn it into a backend server would probably suck, not just because of the amount of work required in an attempt to turn it into something it is not, but mostly because if it loses the inherent advantages it offers as a RAM-resident frontend db server you'll end up with a system that underperforms the competition. I'm wondering why you're thinking about this? Are you trying to come up with a plan to "add value" to WebDNA and perhaps broaden its market by attempting to make WebDNA a suitable system for websites that need more than one server in order to handle extreme loads? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Urgent/Emergency Phone: (228) 222-2917 Website, Database, Network, and Communication Systems --------------------------------------------------------- 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 .
Associated Messages, from the most recent to the oldest:
2507 > 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. Actually in this situation the WebDNA dbs on the slave servers must be flushed immediately BEFORE each rsync overwrites them. If this happens every 30 seconds it will effectively defeat one of the main advantages of WebDNA -- its typically superfast "read from RAM" performance -- because every updated db would have to be read into RAM agai every 30 seconds. > 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. I did something similar many years ago, but instead of frontend and backend servers each server was equally available via a sequential round-robin load distribution system. This eliminated the need to flush the dbs every time one server posted an update to another server, because they would all be posted to at virtually the same time (within a fraction of a second from each other given a fast enough network connection). But when the internet connection between the servers goes down it creates SERIOUS out-of-sync problems such as failure to login, failure to see the updates the visitors just made, etc. ... and this would absolutely require your next idea in order to rebuild the dbs correctly when necessary: > 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. A system like this would become very complex and error-prone in my opinion, thus unlikely worth the effort when non-WebDNA solutions are readily available and have been tested and proven in terms of reliability for many years already. > I am sure there are other solutions. Any other idea? WebDNA's design is ideal for use on a single frontend server. To try and turn it into a backend server would probably suck, not just because of the amount of work required in an attempt to turn it into something it is not, but mostly because if it loses the inherent advantages it offers as a RAM-resident frontend db server you'll end up with a system that underperforms the competition. I'm wondering why you're thinking about this? Are you trying to come up with a plan to "add value" to WebDNA and perhaps broaden its market by attempting to make WebDNA a suitable system for websites that need more than one server in order to handle extreme loads? Regards, Kenneth Grome WebDNA Solutions http://www.webdnasolutions.com Urgent/Emergency Phone: (228) 222-2917 Website, Database, Network, and Communication Systems --------------------------------------------------------- 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 .
WebDNA Solutions
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:
Code for Accessing E-mail Accounts (2005)
WebCommerce: Folder organization ? (1997)
WebCat2b13MacPlugIn - [include] doesn't allow creator (1997)
Running _every_ page through WebCat ? (1997)
Bug Report, maybe (1997)
Mailing Labels (2005)
Online reference (1997)
[WebDNA] WebDNA Roll Call (2013)
We are searching (2005)
Database Fields (1997)
[FEATURE REQUEST] (2004)
Fun with dates (1997)
LetterRip and WebCat (1998)
Dates, Math, and Sandboxes (2003)
Press Release hit the NewsWire!!! (1997)
Next (1997)
WebCat/Typhoon Status under Windows (1998)
problem: search crashes webstar (1997)
Pithy questions on webcommerce & siteedit (1997)
RequiredFields template (1997)