Just to make sure that I understand, the requesting system is waiting 40 seconds for the quote to be returned? Does the quote return need to done as soon as possible or can there be a minute or two before the return?
Maybe have them only submit the record and not trigger the processing workflow. Then have an escalation that will process the new record(s) and then make a call to a web service on requester's end that is designed to accept the return from a previous transaction. It would take some redesigning on both sides but would alleviate the waiting and hanging on to threads/connections. The other thing might be to offload some of the Remedy processing (if there is a lot) to more efficient scripts and/or direct database actions. Web services can be a wonderful thing but not always the fastest. Jason On Fri, Jan 15, 2010 at 3:02 PM, LJ Longwing <lj.longw...@gmail.com> wrote: > ** > 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: > arsl...@arslist.org] *On Behalf Of *Rick Cook > *Sent:* Friday, January 15, 2010 3:55 PM > > *To:* arslist@ARSLIST.ORG > *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 <lj.longw...@gmail.com>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: >> arsl...@arslist.org] *On Behalf Of *Rick Cook >> *Sent:* Friday, January 15, 2010 3:39 PM >> *To:* arslist@ARSLIST.ORG >> *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 <lj.longw...@gmail.com>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: rmisoluti...@verizon.net ARSlist: "Where the Answers >>> Are"_ >> >> >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> > > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers > Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
