Author |
Message
|
brokerguy |
Posted: Fri Jun 14, 2013 6:59 am Post subject: SOAPInput-service operation routing & additional instanc |
|
|
 Apprentice
Joined: 18 Mar 2013 Posts: 26 Location: Cosmos
|
Hi,
I have a situation. All of our services are having multiple operations, each having their own SLA from TPS, response time perspective. Now, I have been using SOAPInput node with routeToLabel/Label nodes to route to specific operation sub-flows.
The problem is how can I ensure that each operation is assigned certain additional instances to meet the TPS requirement. I am kind of limited with SOAP implementation in WMB. What might be the other options ?
I have DataPower front ending all SOAP/HTTP requests. All requests flows thru DP first. In DataPower I can assign SLM policies at operation level.
Thanks in advance.. _________________ Learning to unlearn, re-learn |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Jun 14, 2013 7:06 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Limited how? WMB does not limit how you implement SOAP replies or track performance metrics, like latency.
Is the "Additional Instances" parameter not working for you?
You've not clearly explained this "problem" you are having. ie. When you load test your flow, when does it break (at what TPS)? What is the goal for TPS and latency? How does your current implementation fall short of that goal? _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
Esa |
Posted: Fri Jun 14, 2013 7:09 am Post subject: Re: SOAPInput-service operation routing & additional ins |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
Split the wsdl into operation specific wsdl:s. Create a dedicated SOAPInput node for each operation wsdl and make them use their own instance pools.
Route requests in DP accordingly.
How does this sound?
Allthough I think that applying an operation level SLM in DP should be enough. |
|
Back to top |
|
 |
brokerguy |
Posted: Fri Jun 14, 2013 7:32 am Post subject: Re: SOAPInput-service operation routing & additional ins |
|
|
 Apprentice
Joined: 18 Mar 2013 Posts: 26 Location: Cosmos
|
Esa wrote: |
Split the wsdl into operation specific wsdl:s. Create a dedicated SOAPInput node for each operation wsdl and make them use their own instance pools.
Route requests in DP accordingly.
How does this sound?
Allthough I think that applying an operation level SLM in DP should be enough. |
@Esa: This sounds good. However, we would have to maintain that many number of WSDLs within DP or WSRR. Also, it would mean that each operation would have to have distinct endpoints. Your thoughts ?
The other option was to use MQ in WMB across the board and still front end SOAP/HTTP in DP. Assumption being that all WS-* items are to be handled in DP anyway. Did not choose this because we would have to create/maintain two queues (request/reply) per operation. Also, have to maintain the map in DP of matching req/rep queues & mapping back the reply identifier. The good part is asynchronous processing in WMB, however, the thread in DP still has to wait for the msg to appear in the reply queue. Your thoughts ?
lancelotlinc wrote: |
Is the "Additional Instances" parameter not working for you?
You've not clearly explained this "problem" you are having. ie. When you load test your flow, when does it break (at what TPS)? What is the goal for TPS and latency? How does your current implementation fall short of that goal? |
I have not done a perf/load test yet. However, the additional instance value would be agnostic of how many operations I have. If I have 10 operations a value of say 20 applies to all of them. I cannot adjust the AI at a per operation level unless I have dedicated SOAPInput for each operation.
@Esa & @lancelotlinc. Your valuable comments on the above reply would be much appreciated. _________________ Learning to unlearn, re-learn |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Jun 14, 2013 7:41 am Post subject: Re: SOAPInput-service operation routing & additional ins |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
brokerguy wrote: |
lancelotlinc wrote: |
Is the "Additional Instances" parameter not working for you?
You've not clearly explained this "problem" you are having. ie. When you load test your flow, when does it break (at what TPS)? What is the goal for TPS and latency? How does your current implementation fall short of that goal? |
I have not done a perf/load test yet. However, the additional instance value would be agnostic of how many operations I have. If I have 10 operations a value of say 20 applies to all of them. I cannot adjust the AI at a per operation level unless I have dedicated SOAPInput for each operation. |
What value is adjusting the Additional Instances at a per operation level? Busy is busy, it does not matter busy doing operation B or operation C.
You are adding complexity to the equation without knowing whether or not you actually have a problem. Don't try to code a solution to a problem that does not exist. Test first, solve the results of the test. Don't shoot first then ask questions later.
You have not demonstrated that there is a problem. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
McueMart |
Posted: Fri Jun 14, 2013 7:44 am Post subject: |
|
|
 Chevalier
Joined: 29 Nov 2011 Posts: 490 Location: UK...somewhere
|
How about having your flow with the SOAPInput simply offload the message to MQ (onto different queues depending on operation), and then have a number of separate flows which each process the operations. The additional instances for these could then be configured individually. |
|
Back to top |
|
 |
kash3338 |
Posted: Fri Jun 14, 2013 6:36 pm Post subject: Re: SOAPInput-service operation routing & additional ins |
|
|
Shaman
Joined: 08 Feb 2009 Posts: 709 Location: Chennai, India
|
brokerguy wrote: |
I am kind of limited with SOAP implementation in WMB. What might be the other options ? |
You are not limited here. It all depends on the design you do.
Few approaches,
1. How many operation's do you have? If it is not going to be too many, you can set the AI value to sum of all these. That should cater your needs.
2. Again if the number of operation's are not too many, have separate WSDL's and separate SOAPInputs with different AI in each
3. Pub/Sub. In you main flow, just have SOAPInput with a defined AI value (the maximum value you can set to based on your Env) and publish the message. Have separate subscribers to implement each operation with separate AI set at each flow level.
I am sure there are couple of more options available if you dig in. |
|
Back to top |
|
 |
Esa |
Posted: Fri Jun 14, 2013 9:41 pm Post subject: Re: SOAPInput-service operation routing & additional ins |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
brokerguy wrote: |
@Esa: This sounds good. However, we would have to maintain that many number of WSDLs within DP or WSRR. Also, it would mean that each operation would have to have distinct endpoints. Your thoughts ?
|
Actually, you can use the same wsdl for all SOAPInputs, because DP can route operations to specific endpoints. Yes, each node will have to have a dedicated URL.
But,
lancelotlinc wrote: |
What value is adjusting the Additional Instances at a per operation level? Busy is busy, it does not matter busy doing operation B or operation C.
You are adding complexity to the equation without knowing whether or not you actually have a problem. Don't try to code a solution to a problem that does not exist. Test first, solve the results of the test. Don't shoot first then ask questions later. |
Exactly. You have DP SLM already throttling the traffic by operation. Implementing the same throttles again on Message Broker, would it really add any value?
Just give the single SOAPInput a proper amount of additional instances, not too many, so that it doesn't start choking with lack of resources.
The point of operation level throttling with SLM is to protect the endpoint from overload while maintaining good service level for important operations. E.g. prioritizing operations that bring revenue over those that don't. And the endpoint to protect is probably not Message Broker but the real service provider endpoint that actually implements the service.
There are many things that you have not told us about your scenario. For example, are all the operations calling the same endpoint or is DP implementing a service facade. But that shouldn't actually change anything.
Adding instances to a flow cannot add resources to the system, it can only be used for restricting and prioritizing their usage. And you are already doing that with DP SLM, aren't you?
Can you ensure response times required by an SLA with SLM and additional instances?
Yes, I think you can to some extent ensure that all response times are within the SLA.
It's just that some of the responses may be "service unavailable" (the throttled requests). But even these with very agreeable response times  |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Jun 15, 2013 4:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You could setup an asynchronous SOAP / Request Reply operation in the broker. This would get called from DP. It would also do an async SOAP request /reply call back onto the broker for the specific operations.
So you'd have one async request /reply flow as a router on the broker and as many flows as operations, individually scalable.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Jun 15, 2013 11:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I think the point is to ensure that there's always threads available for operation A, even if there's a bunch of work coming into operation B, C and D...
My tendency would be to decompose the service in Broker, setting up a group of endpoints for each needed threadpool. Then either put up a front-end service router (Using soapinput in gateway mode or http in gateway mode) or route operations in DP. |
|
Back to top |
|
 |
|