Re: Optimizing write performance

My first question on SCO systems is allways what machine you run them on. By going from a Pentium 100 (Compaq Proliant 1500) to a Pentium 300 (Dell 4200) and from SCO 3.2.4.2/Online 7.10 to SCO 5.0.4/IDS 7.22 we got a 3 to 4 times performance gain before any kind of tuning. The spesifications of the disk drives wheren't all that different. We even used a single 9G drive on the new machine as opposed to two separate drives on the old. This database was on the order of 3Gb with up to about a million rows in the largest tables. If you can't upgrade Informix (and therefore also not SCO) you would probably see a similar performance gain if you installed your old software on such a new machine. Of course by now it should be a 400 MHz Pentium for maximum performance and shortly a 450 MHz. As to RAID or Mirroring you may see some performance gain by using a Mylex or DPT caching controller and implement hardware mirroring in it and possibly striping as well if these controllers can do that intelligently. That wouldn't degrade your write performance while your read performance might become better. However I doubt you will see the kind of performance gain you generally get if you upgrade the whole machine (assuming you do not allready have a new fast machine) with this kind of database. This is however dependent on several factors such as your CPU utilization, amount of memory you have, disk I/O performance and activity and other issues. Over the years we have used Unix on Intel machines we have however allways found that upgrading to a new machine gave us the performance we needed. On Sat, 20 Jun 1998 10:37:29 +0100, Stephen Walmsley <newc0571@sable.ox.ac.uk> wrote: > >Further to the recent discussion about the relative merits of mirroring, >RAID etc., what if I had a database which is updated in bulk and queried >in a really trivial, computationally cheap way and therefore for which I >wanted to maximize insert, update and delete speed but really wasn't >bothered about select speed? > >It's SCO 3.2.4.2 / Online 4.10.UC2 so fragmenting is not an option. >Several tables are huge (i.e. of the order of 4G "data bytes" and 1.3 >million rows). Short of upgrading, what's the best thing to do? I thought >of using plain old raw partition allocation and arranging for the chunk >allocation to happen in such a way that each of the big tables reside on >seperate disks and then do the batch inserts, deletes and updates across >multiple tables simultaneously. Would this give me a speed increase >commensurate with keeping two or three disks busy instead of just one? > >I suspect RAID and Mirroring are out because of their degraded write >performance. Any ideas anyone? > >S > Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html (Now with ODBC info under "Third party products".)