I like the thought of caching information....I could see building a caching table for at least one of the external calls....only one of them is taking a majority of the time...and regarding the external users...they aren't users of course...just a 'system' that's doing parallel calls....and I'm not sure how much the caching will help in the real world, but it's certainly worth a try...:) And OH BOY were we having insert/update lock contention going on. I have been able to work around most of it....and yes, we are doing ID chunking to help with that lock contention. Thanks for the suggestions, I'll see if they help out in real world scenarios.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Misi Mladoniczky Sent: Monday, January 18, 2010 10:35 AM To: [email protected] Subject: Re: Fast/List Concurrent settings? Hi, There must be ways to speed things up. If you are doing 4 slow WS-calls, maybe you should write your own plugin that performs the call in parallel. There are endless possibilities. Maybe you can cache some external data within the AR System to speed things up? Maybe you can cache the actual result of these calls, and return the same "price" for identical requests within the same hour or so, without calling the external services? Are you really having 100 users getting price information simultaneously, or are the "external" calls to your WS doing parallel calls? Maybe you can change the external interface. Have you chunked up your nextids? If you are doing creates, you may end up with threads waiting for the release of a locked arschema-table... Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > LOL.....consider this Rick....Consider a 'submit' to be an interface > that allows ALL attributes needed to completely configure a change > with a single button press. This may be a bad example...if it is I'm > sorry...I really don't do ITSM....but the submit in question on our > system actually averages about 40 seconds. Makes no less than 4 calls > to other external systems via web services and performs more > calculations than I care to think about. > That being what it is....what would you do in that situation? > > _____ > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Rick Cook > Sent: Friday, January 15, 2010 3:55 PM > To: [email protected] > Subject: Re: Fast/List Concurrent settings? > > > ** If your submits are taking 10 seconds each, you have a significant > problem, my friend! > > Rick > > > On Fri, Jan 15, 2010 at 2:52 PM, LJ Longwing <[email protected]> > wrote: > > > ** > I completely agree with everything you said....but as you mentioned, > if you have 60 submits and have 10 threads...you are only handling 10 > of those 60 concurrently....so if each transaction takes an average of > say...10 seconds...the first 10 will complete in 10, the next 10 in > 20, and so on with the final set of 10 taking a full 60 seconds from > time to complete to process. If your external application has a > timeout of say....45 seconds then you are only going to be able to > handle 40 of the 60 submitted concurrently and as such would have a > 1/3 failure rate....in that situation would you then set your threads > to say....15 to make it so that you could handle 60 in 40 seconds or > would you take it to 60 to be able to handle 60 in 10 seconds? > > _____ > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Rick Cook > Sent: Friday, January 15, 2010 3:39 PM > To: [email protected] > Subject: Re: Fast/List Concurrent settings? > > > ** I would think that one of the larger software-related issues that > would affect the number of concurrent Inserts would be the Index > structure. I am sure you know this, but for the benefit of those who > don't, indexes are meant to help us search on a form more easily. > However, above a certain number (around 8 for a Remedy form), that > cause performance degradation when creating a new record, because each > of the indexes has to be updated as part of the creation process. If > a system is seeing slow creates, that's the first thing I check. > > > One other thing to think about is that since each thread can cache 5 > processes (that's the last number I heard, anyway) in addition to the > one currently being handled, you could, with 10 Fast (Single-API) > threads, handle 60 concurrent create processes without a transaction > loss. There would probably be a bit of a delay for those farther back > in the queue, but if you had a reasonably robust system, most users > wouldn't notice it much. > I seriously doubt all but a very few systems have to handle anything > resembling that kind of concurrent load, with the exception of those > who have a large number of system (i.e. NMS) generated records. > > Also look at the Entry ID Block size when doing this test. If - AND > ONLY IF > - you are regularly having large numbers of concurrent inserts, you > can set the Entry ID Block size to something like 10 to cut down the > number of requests to the DB for Entry IDs. That is alleged to help > with create times, though I have not seen that be the case in > practical use. > > Rick > > > On Fri, Jan 15, 2010 at 2:27 PM, LJ Longwing <[email protected]> > wrote: > > > ** > Here is an interesting question for you thread experts out there. > > How many concurrent 'creates' does your system support? Creates being > a generic term for any given process that your system supports. The > system that I support is a home grown quote/order management system > and last year we stood up a web service interface for people to be > able to generate quotes from their systems and get pricing back. The > initial interface was setup to handle 3 concurrent creates...but as > soon as it was a success we started getting slammed with several > hundred at a time and choking our system. > Through rigorous testing and tweaking over the last couple of weeks I > have been able to get roughly 60 concurrent going through the system > with reasonable performance....so at this point I have my Fast set to > 30/100 min/max....confirmed that I'm not maxing anything specific > out....but I personally have never run above 20ish threads as a high > because most transactions are short and a fast thread count of 20 will > handle hundreds of users in 'normal' operation.....so I was just > wondering how many requests you guys have your system to handle > concurrently....and just for verification...I'm talking about 'all of > them hit the button within a second of each other' type of > concurrent...not 'I hove 400 people logged on concurrently' > _Platinum Sponsor: [email protected] ARSlist: "Where the > Answers Are"_ > > > _Platinum Sponsor: [email protected] ARSlist: "Where the > Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: > "Where the Answers Are"_ > > > _Platinum Sponsor: [email protected] ARSlist: "Where the > Answers Are"_ > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > > ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
