I need some suggestions for horizontal scalability of SonicESB processes/services. I've been using MQ/ESB for a relatively long time off and on with various clients (over 6 years) and having to put more MFContainer/ESBContainers on servers to get more instances of actual processes/services has always rubbed me the wrong way as a scalability nightmare on a production platform. It seems like it would be a clunky (I hesistate to use the term 'difficult') scaling solution to keep up with over time as load increases without having to continually think about adding hardware/servers.
Are there any plans to build a process/service scalability into the framework so that when you deploy a process/service into an ESB container, the number of instances of that process/service could be controlled at the container loading configuration or framework level much like the number of listeners per process or service is controlled now? Could this be something abstracted into the framework?
Thanks in advance.
Hi Chris,
I take it you are aware that a service with a given name deployed to a container will just be one Java object and that the # listeners equal the max # threads that can pass throught the service() method concurrently. So one option at hand is to add another instance (with a different name) to the same esb container but performance wise it would not make much of a difference since its just a few more # threads that pass throught the same service() method. Only with a different ESB container, no matter if on a different MF container or not, you will get different behaviour. The main differences are:
Having said that: how do you define the term instance? And what exactly do you want to scale? The JMS connections? The memory for the service? The location of the service? Something like a max total # listeners/instances per domain?
Or rephrasing: What business use case do you want to solve? What is your top-level problem?
Thomas
Hi Chris,
I
take it you are aware that a service with a given name deployed to a
container will just be one Java object and that the # listeners equal
the max # threads that can pass throught the service() method
concurrently. So one option at hand is to add another instance (with a
different name) to the same esb container but performance wise it would
not make much of a difference since its just a few more # threads that
pass throught the same service() method. Only with a different ESB
container, no matter if on a different MF container or not, you will get
different behaviour. The main differences are:
Having
said that: how do you define the term instance? And what exactly do you
want to scale? The JMS connections? The memory for the service? The
location of the service? Something like a max total #
listeners/instances per domain?
Or rephrasing: What business use case do you want to solve? What is your top-level problem?
Thomas
Thomas thank you for the reply.
Our top level problem is multiple clients submit a status update message to us (SonicConnect exposed web service operation) on relatively short, periodic intervals. Two services must separately act on each incoming request message. One service updates a database with pertinent statuses sent in and is not required to respond to the client. The other service is responsible for reading the database and crafting a synchronous response message to the client. We would like to maintain throughput and a respectable overall response time to the submitting clients as the number of clients increases. Typically, we will deal with up to 3 clients submitting a 500k-1Mb SOAP/XML message and the sychronous response is on the same order. Their requests are sent constantly every 7 to 10 seconds, depending on the client.
Understanding everything you've noted about the variations we could architect or configure to handle this, we are empiracally and intuitively seeing slower test times when we would believe we ought to see better times. When we use multiple MF/ESB containers with the same services deployed in each (with or without intra-container messaging), we see slower times for responses than if we use a single MF/ESB container. When we use a single MF/ESB container with 1 listener per process/service pair, we continually get slightly faster overall response times than if we use 5 or 10 listeners per process/service. We're a bit perplexed about why the additional "pipes" would not allow for faster throughput.
I was using the term "instance" to refer to each, named service deployed in a container - so, each Java object.