Re: ESQL/C library functions - Any change from 5.x to 7.x
On Wed, 8 Oct 1997, Richard Spitz wrote: > Art S. Kagel wrote: > > Anyway, I have never found the relay module to be a bottle neck > > compared to 5.0x native access at all. > > How does the overall performance of your engine compare to the > previous 5.x version? Are you using the same hardware for the > 7.x engine that you used for the 5.x engine? > > I can imagine that 7.x on faster (multiprocessor?) hardware outper- > forms the previous engine by so much that the performance hit delivered > by using the relay module is more or less neutralized. > > In our case, we cannot afford to buy new hardware. Since on several > occasions people from Siemens-Nixdorf (our hardware and OS vendor) > and from Informix told us that on our single processor machine there > would be no noticeable performance benefit from 7.x, we have so > far refrained from an upgrade. The relay module would certainly make > things worse. ODS 7.xx benefits most from its ability to better utilize SMP and other multi-processor systems than the OL5.0x line, this is true. I have found that for simple queries on simple tables, especially on single CPU machines, 5.0x is faster though not by much. If on the other hand you applications and database structure can take advantage of 7.xx features, or more important needs them, then the performance gains from these features can quickly overwelm the added overhead and you will fly past 5.0x. To wit: If you have a large database, 5.0x is limited to 64 chunks per instance if all of the chunk pathnames are 2 characters long, ie /a /b /c /d, otherwise this is less seven character pathnames, ie /i/abcd yield 54 chunks maximum. This effectively limits the size of your database to 108GB if all chunks are 2GB and you have no tempspaces or separate log spaces and you use the rootdb space for data tables. ODS 7.xx extends this limit to 2048 chunks making the maximum practical database 4TB and Informix is working on supporting chunks larger than 2GB in ODS 7.xx on systems with an extended fseek() function. This feature will probably never make it into 5.xx. Detached indexes are a great boon on multiprocessor machines because they increase the overlapping and parallelization of searches. Even on a single processor this can improve access times for indexed searches. Fragmented tables permit tables to grow beyond 32GB the limit to table size on 5.0x. Fragmentation allows maximum parallelism on multiprocessor systems but can also improve performance on single processor systems by reducing the number of rows that must be searched if the fragmentation scheme matches the search criteria. Imagine how much faster things ran when your database was 1/4th or 1/10th it current size, what happens in a year or two as the tables grow? Accessing foreign tables, ie tables in another database whether in the same or another engine, can be much faster using multiple connections supported by ODS 7.xx. ESQL/C 7.xx is thread safe and so multi-process applications can be recoded using threads which reduces system overhead freeing resources for other processes including the Informix engine. I could go on but you get the point. You must evaluate your database and your applications and take account of the features that you might be able to take advantage of to make this decision. I have the perfect analogy. Yes, you can get on your horse and be gone up the block before I unlock my Ford Expedition, but then what I'll pass you at the corner. In addition your horse cannot haul 8 adults or a china closet 320 miles nonstop at 70MPH either. I'm not saying "Dump 5.0". I am saying "Use the right tool for the job. Here is a new one to look at. It cannot drive a nail well, but it does a much better job of driving screws than a hammer." Art S. Kagel, kagel@bloomberg.com