Rick, I don't believe that Misi is saying that the ARServer doesn't treat them differently, it does, I think what he's saying is that there is no fundamental difference between the performance of the thread itself...a thread is a thread. Looking at my ARLogAnalyzer output I can tell what kind of thread it is by what calls go to it...in my testing of this subject my fast threads have the following calls XMLCE = ARXMLCreateEntry GLS = ARGetListSchema GEI = ARGetEncryptInfo VER = ARVerifyUser GSI = ARGetServerInfo GLG = ARGetListGroup
My List threads have the following GLEWF = ARGetListEntryWithFields EXP = ARExport GLE = ARGetListEntry EXECAL = ARExecuteProcessForActiveLink EXPQRY = ARExpandQueryMenu All that being said, a create through web services uses the XMLCE call which goes through fast. Regardless, for concurrent processing I need a thread for each concurrent effort. So the question still stands....have you ever come across a need for a high volume of concurrent efforts and what's the highest Fast/List settings you have ever felt the need to use? _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rick Cook Sent: Monday, January 18, 2010 6:42 AM To: arslist@ARSLIST.ORG Subject: Re: Fast/List Concurrent settings? ** Misi, I know that you know AR System internals very well, and so normally, I would never question you. So consider this response with that in mind, as well as the disclaimer that this is the last thing I was taught on the topic - if the architecture of the internals has changed, I must have missed that memo. The purpose behind Fast and List threads was to separate single-API functions (Submits, mostly) from multiple-API functions (pretty much everything else). The thought, from what I can infer, was to have an express line of sorts so that quick DB transactions wouldn't have to wait in line behind long search/retrieve tasks. If, as you infer, Fast/List threads no longer have any relevance in terms of different function, why do they still exist as separately tunable parameters? Rick On Mon, Jan 18, 2010 at 5:06 AM, Misi Mladoniczky <m...@rrr.se> wrote: Hi, I do not think that updates from Web Services use the list threads. It would be the same thing as the Save-button in a Modify-form. It performs a ARSetEntry()-call through a Fast-thread. It is performed by the Mid-Tier-server just as any other client. The Fast- and List-threads are just a blunt way to group and route various calls. If we exclude the admin-tool/developer-studio calls, I think that any call with "list" in it's name access the List-servers and any call without "list" in its name go to a Fast-server. There is no technical difference between Fast and List threads. They perform in the same way. As a Fast-call can be very slow, and List-calls very quick, I would argue that differentiating between these types of calls are not that useful. The calls to the fast an list threads typically comes in pairs anyway: An ACTL-Set-Fields performs two calls. One ARGetListEntry() to the List-thread, and one ARGetEntry() to the Fast-thread. An ACTL-Push-Fields performs a ARGetListEntry() and an ARCreateEntry()/ARSetEntry() call. In the old days, I think that the List-threads and Fast-threads had another distinction. When a user logged in, he was "assigned" to a Fast-thread but accessed the List-thread in a more random way. The idea was to minimize the calls to the transaction-daemon and portmapper to find the tcp-port of the fast-threads each time they were called. Now everything goes to a single tcp-port. When we got the FLTR-Push-Fields calls, the ARCreateEntry() and ARSetEntry() calls stopped being very fast. WebServices adds even more to this problem. In most cases, it is possible to rewrite workflow to be much faster. In some cases, especially with the bigger apps such as ITSM, it is more difficult. And you do not want to customize ITSM anyway... 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. > As an aside, technically your submits are going through the Fast > (single-API) threads, while your updates from Web Services would use the > List (multiple-API) threads. That's if your submit is allowed to finish > and > then the ensuing record is updated by the WS. If the WS return values are > part of the Submit process, then you have long transactions processing > through and clogging up your Fast threads, which is not what they are > intended to handle. That will be the case regardless of the source of the > external data retrieval process or source, though the time they take may > be > affected by using DB vs. WS. > > Rick > > On Fri, Jan 15, 2010 at 3:35 PM, Jason Miller > <jason.mil...@gmail.com>wrote: > >> ** 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"_ >>> >> >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ >> > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:rmisoluti...@verizon.net <mailto:sponsor%3armisoluti...@verizon.net> 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:rmisoluti...@verizon.net <mailto:sponsor%3armisoluti...@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"
