Hi Stefan,
Nice summary as usual. I would point out that we are opening up the
commercial product to match Sequoia--we have found the reasons you
cited for extra controllers are quite compelling in some cases.
One of the issues we are working through as we do the implementation
is that the group communications packages that can run more than 2
nodes seem to operate quite a bit slower than our proprietary group
comm for the 2 node case. We're still investigating the root cause
of this behavior. It's not a matter of the number of messages we are
generating on our side--it's equal in all cases.
Cheers, Robert
Robert Hodges, CTO, Continuent, Inc.
Email: [EMAIL PROTECTED]
Mobile: +1-510-501-3728 Skype: hodgesrm
On Aug 31, 2007, at 6:54 AM, Stefan Lischke wrote:
Hi Bo,
Interesting question! We are discussing this too. Some thoughts about
it, but no solution or hint.
pro:
* more controllers gives you a higher reliability if one or more
controllers fail.
* more controllers gives you a better load balancing. If the right
loadbalancing policy is chosen. remember the sequoia jdbc url contains
all controllers and if you do round robin the requests will be
distributed to all controllers.
contra:
* more controllers generate more administration time. Starting,
stopping, syncing...
* more controllers generate more adminsitrative traffic among all
controllers. Remember a sql-insert sent to one controller must be sent
to all other controllers.
* more group communication and process time. To keep a cluster with 4
nodes running, more group communication and process time for this is
needed compared to just 2 nodes. I think it will be 3 time more
communication/process time by just doubling the number of
controllers.
I think the answer is "it depends on". If your application does a
lot of
sql-insert/updates, i would choose only 2 controllers to minimize
sql-insert/update replication and group communication overhead.
If your application is mostly using sql-select, i would choose 4
controllers to speed up everything, cause selects are not
replicated to
any node.
btw. If you look at the commercial sequoia software made by
continuent,
you see, that they only use a 2 controller scenario everywhere. They
enhanced this scenario by creating their own group communication
protocol "duocom" that only works between 2 nodes.
hth
stefan
Bo Glenn wrote:
Is there anyone, preferably a Sequoia project team member, that can
assist me with this question? We have 10 application servers that
are
going to be connected to 2 postgres database servers via Sequoia
controllers and I would like to know if I need to have more than two
controllers. I am interested in hearing arguments for or against
having
multiple controllers. Is it better for performance, scalability, are
there known issues/reasons for not having more than two,etc. Please
reply as we need to work on our implementation plan. All help/
comments
are appreciated.
Thanks,
Bo
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bo
Glenn
Sent: Wednesday, August 29, 2007 5:47 PM
To: [email protected]
Subject: [Sequoia] using multiple controllers
I would like to know if there is a benefit from using more than two
controllers. We currently have enough hardware to have 4 controllers
with 1 controller per physical machine (4 servers). Our
application is
mutli-threaded and does a large number of write and read
transactions.
Does it make sense to have more than two physical machines running
one
controller each? Is there a performance gain for having more than
two
controllers for example 4 controllers to spread the communication
to the
backend database servers for JDBC transactions?
I have researched the archives and the documentation and I cannot
see an
argument for or against using more than two controllers like the
basic
setup uses. It would be great to know if we should leverage our
hardware or if we just need two controllers.
Thanks in advance for any assistance.
Thanks,
Bo
+--------------------------------------------------------------------
--+
| Z1 SecureMail Gateway Info - http://
www.zertificon.com |
+--------------------------------------------------------------------
--+
| - Die Nachricht war weder verschluesselt noch digital
unterschrieben |
+--------------------------------------------------------------------
--+
---------------------------------------------------------------------
---
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Zertificon Solutions GmbH
Landsberger Allee 117, 10407 Berlin, Germany
GF: Herbert Nebel, Dr. Burkhard Wiegel
HRB 94059, AG Berlin-Charlottenburg
http://www.zertificon.com
https://www.globaltrustpoint.com/[EMAIL PROTECTED]
+49 (0)30-5900 300-0 (fax -99)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Z1 SecureMail" by Zertificon
...the leading server solutions for Secure & Trustable E-Mail
Try our Policy controlled S/MIME & OpenPGP & HTTPS Messaging!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
