Re: Number of users and performance

Ronald Twaddell wrote: > > We are currently running online 5.0 and Fourgen Enterprise 4.1. > The problem is performance. Everything seems to be fine until we run > our posting processes. The all hell breaks loose and many programs start > to terminate due to lock time outs! > We have tuned the database and the kernal! > The machine is an RS6000 590H, Single Processor, wiht 512MB Memory. > We also have an SSA Disk array! I peak we have about 80 users on the > system. > I have a feeling we just have run out of horse power for the single > processor, but am wondering if this is true. > Also I am wondering how much moving to informix 7.x would buy us! > > Any sugestions or Comments? > > Thanks...rrt@worldnet.att.net Ronald, You claim that this is a performance problem but you describe crashing programs. Try looking at the problem from the perspective of what the application is doing rather than the probable user complaints of poor performance. Careful review of the description of the problem to make it precise and complete can often help to guide you into resolving it. Below is a couple of alternative views of what could be causing your problem based on the limited description you provide. They aren't necessarily correct just different views to investigate. Your description suggests that your posting program is taking and holding locks for long periods of time. That seems to be a problem with the transaction design of the posting program rather than a performance issue. Try redesigning it so that it doesn't, I'm guessing here but it's a common mistake, do the whole or major parts of the posting run as a single transaction. Alternatively only run the posting program when nobody else uses the tables that it needs. This is a very common method of avoiding otherwise unavoidable conflicts between the needs of the two types of programs. If the above is correct then the performance problem is probably caused by the other programs sitting idle while they wait for the locks to be released by the posting program. If they sit too long they crash and this is completely dependant on what the "Set lock mode wait ?" has been set too within the programs. It's not that they are performing badly, its that they aren't able to continue working at all. A review of the posting program design and lock waits within the engine is required to assess this. Alternatively you could be running into performance issues with the disk array. There have been a number of discussions recently on disk arrays and RAID configurations in this forum recently. Some are for arrays, some are against what I can say is that disk arrays used wisely at whatever RAID level are probably as good as and often better than traditional disk farms. BUT they can be a complete disaster if the way the database is laid out on the array conflicts with either the design principles of the array or of the application. If this kind of mistake has been made the performance for different parts of the application can go completely down the tubes. A review of the array i/o performance and array cache hit rate both during normal processing and posting processing is required to assess this. As for running out of horsepower. It's possible but that wouldn't normally cause lots of programs to crash with lock timeouts. Use the tools available to see how heavily loaded the processor is during posting processing and under normal load. But remember just because this shows up an overload on the processor during posting doesn't necessarily mean that you have an underpowered box. It could mean that the design of the posting program is bad and all this additional processing power use is unnecessary. This applies as well to any i/o overload on the disk array during posting processing. There again it may be cheaper to buy an additional processor than to fix the program. As a general comment moving to V7 on a single processor box will probably have limited impact on performance and may in fact reduce performance. This very much depends on the skill of the person tuning the engine and the type of application being run. Hope this helps. Cheers - Jim -- ------------------------------------------------------------------------ Jim Gordon DHL Airways Inc. jgordon@us.dhl.com ------------------------------------------------------------------------ My opinions are my own. They may vary with time but they remain mine!