Why do you have a scheduled task? What happened to using an adapter notification like you had mentioned in the very beginning?
Percio
Thanks RMG & Percio for your replies.
RMG : I specified trigger as concurrent thread processing.
Percio: I wrote a storedProcedure which brings documents from DB which is been called from a flow service, it is a business demand, so there is no other go for me.
RMG: As per concurrent thread processing I set threads as 10, i am sorry not to specify in my earlier post.
Thanks,
There is a stored procedure notification too. But in any case, let’s just assume that for now, you have a scheduled task of some sort, whether using notifications, scheduler, or whatever.
First, without knowing anything about your data, system, code, or anything about the web service provider’s data, system, code, etc, it’s impossible for us to tell you how to configure your application to hit a target throughput. When it comes to performance questions, the only way to find answers is to actually test and take measurements.
Having said this, if you have a hard set requirement of 30k per day, publishing 200 documents every 10 minutes will give you a max of 28,800 documents in a 24-hour period so your current approach is a bit problematic.
A couple of things:
-
Why limit yourself to 200 documents at each interval? The way I see it, once your scheduled job wakes up, it should send everything that is currently available and not go back to sleep until it’s done. If you don’t do this, it can be very easy to end up with a backlog that you can never catch up to.
-
Why limit yourself to only running every 10 minutes?
Now, let’s talk about the numbers a little. Instead of taking some wild guesses at “how many documents” and “how often”, you need to convert your requirement into something that is measurable and then you need to go perform some measurements. Let’s give it a shot:
30000 transactions per day / (24 hours per day * 60 minutes per hour * 60 seconds per minute) = 0.35 transactions per second (i.e. tps)
With this number in mind, you can now run a load test and measure your throughput to see if you’re in good shape. Another way to look at this number is that 0.35 tps means that a single transaction has about 2.86 seconds to complete. So, you could run a single transaction through end-to-end to see if you’re meeting this basic guideline. If so, then things are looking up. Of course, a true load test would be a much better indication of actual throughput due to multithreading, stress on the system, and other factors.
Hope this helps,
Percio
Anil,
Concurrent with 10 threads is good to start with but you may need to bump up to 20 or more only based on your performance matrix requirements and as always load test in this case would be good based on the comments out from Pierco and then come to conclusion on the bottle necks with your logic/IS/Broker server resources wise or any DB layer latencies etc…
HTH,
RMG
Thanks Percio & RMG for your inputs. Will perform the load test and will change the settings as needed.
Thanks,
Good deal…and pls keep this thread posted!