Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Quick, Easy, iSeries Performance Improvement

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quick, Easy, iSeries Performance Improvement

    It details how to set and then monitor changes to the interactive time slice. Wouldnt using Performance Data be helpful to determine how many and which of your jobs are hitting time slice end. I haven't administered systems, for years now, but I am wondering, does the technique I describe still work? I dont think this would be a good strategy on medium to large evironments. I think there are other factors such as the Time Slice End Pool, Performance Adjustment, Dynamic Performance Bands, multiple subsystems, multiple classes in subsystems that are more significant in helping prioritise the work. Has anyone had good success trying some of the things I wrote about? No. I tend to take a more business approach. Sometimes there are business important transactions/processes that are complex but are high priority. The dependency on the TimeSlice alone doesnt take that into account.

  • #2
    Quick, Easy, iSeries Performance Improvement

    Some of the things you mention like the dynamic performance tuning component of OS/400 and the Time Slice End Pool were not available when the article was written, however, by reducing interactive time slice, I believe I make those processes you mention more effective. I like what you said regarding multiple subsystems, or I should say different subsystems for different types of work. That's working with, not against, the architecture of the System/38, er, I mean iSeries. Still, I am talking about QINTER only - or whatever people name their interactive subsystem(s)- and my feeling on QINTER is that if the transaction cannot complete in 2000 milliseconds, it's hurting performance whether their is a performance monitor to reduce the priority, or a time slice end pool. I'll go as far and say that if the transaction in QINTER cannot complete in about 100-200 ms it's hurting performance. As far as complex business transactions, those, and crappy code like I have in my shop that makes 100 chains and 50 updates when the enter key is pressed is EXACTLY what I wish to reach time slice end so performance tuner can eventually kick in and do it's thing. The sooner those CPU hogs reach time slice end, the better.

    Comment


    • #3
      Quick, Easy, iSeries Performance Improvement

      Way back in 1990, I took an IBM course in New York City on improving the performance of the (then) AS/400. Briefly, the technique involves the reduction of the interactive (QINTER class) time slice. The article I wrote way back when has been reproduced on my web site here: Improving iSeries Performance It details how to set and then monitor changes to the interactive time slice. I haven't administered systems, for years now, but I am wondering, does the technique I describe still work? Has anyone had good success trying some of the things I wrote about? Thanks to all.

      Comment


      • #4
        Quick, Easy, iSeries Performance Improvement

        However, by reducing interactive time slice, I believe I make those processes you mention more effective. I am not sure I follow/agree. If the dynamic performance tuning is being applied, which alters a thread's priority how does reducing the timeslice make it more effective ? I think you are assuming Static Priorities ? As far as complex business transactions, those, and crappy code like I have in my shop that makes 100 chains and 50 updates when the enter key is pressed is EXACTLY what I wish to reach time slice end so performance tuner can eventually kick in and do it's thing. This is where we disagree. I think there is a business context of the priorities. Example: We are looking to approve credit applications online, this involves a Fraud Detection task. The Fraud detection can be CPU intensive. The business goal is to have online applications processed as fast as possible. If we took the above approach Fraud Detection would be tagged as a Hog and downgraded with the nett effect the overall application process will take longer. I see more businesses wanting to take what was batch processing capabilities and bring them online/real time. This can mean some steps in an online process can be CPU intensive. In my opinion if they are important to the business they should be prioritised in the system accordingly.

        Comment

        Working...
        X