RE: multiple threads using Informix 4gl
Posted in 2000
This does not sound right. You should get at least 4x better performance. Perhaps tune INFORMIX to use all 4CPU and check again for interest. I wrote a similar program to do unloads of very big tables on ONLINE 5. The program split the table in 10 {variable parameter passed} pieces, forked 10 processed to do unloads. This was done a 4 CPU server with no users. I found between 10 and 12 forks to be the fastest. All CPU's where running at 100%. It even out performed HPL but true comparisons where not done. {PS, tables on raid 10, 8 disks}. Perhaps you are running into some lock problems. What ver of INFORMIX ? Onconfig ? Table or row locking ? What else is the DB doing, user's onstats ? -----Original Message----- From: Eric Fontaine [mailto:Efontaine@houston.rr.com] Sent: Friday, September 01, 2000 6:43 AM To: informix-list@iiug.org Subject: multiple threads using Informix 4gl 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.