Ifx problem with esql 7.24 dce HPUX1020 PA-RISC20

Hello, We have also encountered performance problem at the begin. 0f 1999 when moving our informix software from HP-UX 9.0x to HP-UX 10.20 on K580 machine (PA-RISC 2.0). Our application is a DCE server that calls informix ESQL/C routines stored in our own shared library. I've heart Rumors that DCE thread on hp-ux (posix draft 4=user thread) are uncompatible with informix thread (MIT thread, is it true that informix uses MIT thread ?) which generates in kernel execpetions that took half of processor time. The problem is that we had not enough time to verify that, and we executes such patch on thios K580 machine which enable to have good performance. PHKL_12830 PHSS_16429 and also: PHCO_16591 fsck_vxfs(1M) cumulative patch PHKL_16751 SIG_IGN/SIGCLD,LVM,JFS,PCI/SCSI cumulative patch PHKL_16957 Physical dump devices configuration patch PHKL_17013 LOFS cumulative patch PHKL_17254 Correct process hangs on ufs inodes PHCO_17389 LVM commands cumulative patch PHKL_17717 VxFS (JFS) mount,fsck cumulative changes PHNE_17730 cumulative ARPA Transport patch (the above replace PHKL_13261) However, on this machine we continue to have problems (Assert of informix ......). The DCE server in fact launches only one DCE thread; and client request are treated sequencly (FIFO). So we have decides to link static informix library instead of thread safe informix library. Can it explain problems we faced with. More generally speaking is there much informix problem on HP-UX 10.20 PA-RISC2.0 than on HP-UX 10.20 PA-RISC1.1 ???? Thank you very much for your help. P. Gineste PS: here is explained more precisely performance problems we encountered along with exact configuration and tries we made to locate this performance problem. -> strange. ______________________________ Reply Separator _________________________________ Subject: Performance problem with esql 7.24 dce HPUX1020 PA-RISC 2. Author: pascal-gineste-at-om (pascal_gineste@non-hp-france-om4.om.hp.com) at HP-France,mimegw8 Date: 18/03/99 11:36 Currently we have a performance issue. We run different flavors of the same application on two different machines, and it appears that, under some circumstances, one of the flavor of the application runs slower on the fastest machine. Here are the details. ============================================================= I> The two systems ============================================================= future production system where we have the performance issue) : =============================================================== PA-RISC 2.0 esql 7.24.UC6 dbaccess 7.24.UC6 processor K460 (4-way) HP UX 10.20 4 GB Memory 32 GB disc space for apps 10 GB disc space mirrored for database Informix 7.24 database developpement system and reference for our performance tests : ================================================ PA-RISC 1.1 esql 7.23.UC4 dbaccess 7.23.UC4 processor K410 (2 - way) HP-UX 10.20 <1 GB memory 4 GB disc space for app and database Informix 7.23 database ============================================================= II> The Application ============================================================= The application is a DCE server with informix accesses. It has been compiled under HP-UX 10.20 on a PA-RISC 2.0 platform, but with the options +DA1.1 +DS1.1, to make sure that it runs on both the development and the new server. The DCE server calls functions embedded in shared libraries that we have developed, and those functions evenutally call informix using embedded-SQL. All the programs hereafter are compiled on the development machine (feroe) The following libraries are compiled with the archive flags: libm.a libV3.a libcl.a libsec.a libdce.a (dce) libc.a libixsql.a (informix library) libixglx.a (informix library) libixasf.a (informix library) libixos.a (informix library) libixgls.a (informix library) libnsl_s.a Those objects are the application's heart and linked to it: end.o checkapi.o (informix) The follwing shared libraries are dynamically linked: libCNS.sl (dce) libdld.sl libixgen.sl (informix library) To narrow down the problem, we have made different tests, even by creating smaller/simpler applications to compare performances on both systems. In either case, the applications have been compiled on the feroe system with the +DA1.1 +DS1.1 option, and then copied on to the new production system. ======== First try ======== We built a simple C program doing a huge loop, with and without i/o (printf or no printf) in the loop In either case, the program runs twice as fast on the production system than on development system, which turns out to be normal. ======== Second try ======== We created a embedded-SQL program that does the following: for i in 1 to countermax DECLARE cursor OPEN cursor while existing row FETCH end while end for In this try, it is a standalone application, that is, we don't link the DCE and CNS librairies with i (so it has nothing to do with DCE). In that case also, it runs twice as fast on the new production system than on development system, which is still logical. ======== Third Try ======== We reuse the code of the first try, but embed it in a DCE server. So the application does exactly the same thing than on the first try, but it is a DCE server and we call it through a DCE client. In that case as well, the application in the DCE server runs twice as fast as on development system, so it is always the logic. ======== Fourth Try ======== The code from the second try is inserted (like in third try) into a DCE server, and we do the same test as in the third try. This is where we run into the performance issue: the DCE server runs 10 times slower on the new production system than on development system. Thus we feel that we have a specific problem when we use embedded informix in a DCE server. Specifically about that case: - When we use glance, we see that on the development system the processor is used at nearly 100% by the informix processes (online). While on production system, those processes only use at most 5% of the processor, and the processor nearly does nothing. It looks like the machine spends its time at waiting (but for wh