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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
