Re: multiple threads using Informix 4gl

Thanks for the feedback - I've checked for row-level locking, network I/O is fine - the two machines are gigbit between them. Disk I/O looks good, and CPU's don't seem taxed (I'm using Monitor and vmstat to check this - is there something better?) Bob (Brett?) - good point about the shared vs. static-linked, but I don't know what that means (sorry) - I'll check it out and see if there is something there I can work on. "Art S. Kagel" <kagel@bloomberg.net> wrote in message news:39AFF9DB.60FEA1ED@bloomberg.net... > Make sure all the tables are using ROW MODE locking not PAGE MODE locking > which will block more. That is the likely cultprit. > > Art S. Kagel > > Eric Fontaine wrote: > > > > Ok, people - first post here. > > > > First off - I'm not Informix knowledgeable in anyway - I seek the advice of > > you, the experts...I'm actually a software development team lead trying to > > keep an older Informix middle-tier alive a little longer. > > > > So here's the setup (sorry for the length): > > > > We have a 4gl program which performs an interative process - say summing up > > year to date taxes collected from a number of checks for an individual (but > > imagine something a bit more complex). The current program fetches a list > > of people, then goes through the list one by one, performing the necessary > > calculations, going to the next person, and so on. > > > > What I've asked to be done is to break the list apart, and calculate details > > for several people at once, since one person's totals aren't linked in any > > way to anothers, the purpose being to get the job done quicker. > > > > The "program" is actually several 4ge's - the first determines the list of > > people, then launches several copies of the primary program, passing it > > parameters so each copy will know what it's slice of the pie is. > > > > They have done this, with some interesting results...it seems that if we > > break the list into two equal parts, the overall process is only slightly > > faster. We've tried breaking it out into 2, 4,6,12, and 16 separate > > processes - with 12 separate programs taking about 40% less time. The CPU > > and disk I/O on the box doing the work are ok - more than 70% free. > > > > So the question is - has anyone done anything like this? And if so, how > > come with 3 "threads", we don't see a more significant reduction in > > processing time? > > > > If it helps, we're running this on an RS6000 running AIX with about 2 gig > > RAM (guessing, but at least a gig), and 4 CPU's. The database is actually a > > separate box, similarly equipped.