We're currently trying to speed up our system. It seems that using table boosters may improve the performance of some sessions which run in batch but we're not sure if there won't be a "side"-effect if we do it as it is described in the documentation. The problem is that some sessions use tables which have a real huge amount of records and - according to the documentation they should be fully read (+5%). What happens if there is no more memory available? I guess everything will become slower instead of being speeded up. Our server has 16 GB of RAM but it still may be not enough...

Any suggestions?

Do you have test systems? I recommend trying it there just to see what happens. I do not recall any problems(we are on 4c4) and the boosters definetly did speed up some of our batch. Do it once without boosters and then once with - simulate a nightly run.

Of course we first test it in our test environment. I also wonder what's up with the parameter in bse_vars where you can override the maximum size of a booster (which is 5 MB by default). We've set it to 10 MB which still may be too little (what about setting it to 100 MB since it's only for batch purposes and we just have these 16 GB of RAM which I guess is not used at all in night time).

table boosters are pointless with modern databases. They were there to help tbase.

Informix will do a better cache job than any table booster.

The only Performance Boosters that matter are turning off progress bars
and parallel server.

If you want to speed up your server - look to your database.


Dave

So you recommend to deactivate the table boosters and only keep the parallel servers active. Hmm.

table boosters are pointless with modern databases. They were there to help tbase.

Informix will do a better cache job than any table booster.

The only Performance Boosters that matter are turning off progress bars
and parallel server.

If you want to speed up your server - look to your database.


Dave

Not sure I know enough to argue the point - the only booster we have set is the number of servers. I know running Generate Planned GRP Orders is about twice as slow as when we run it manually. In what way are you recommending we look at the database?

Not sure I know enough to argue the point - the only booster we have set is the number of servers. I know running Generate Planned GRP Orders is about twice as slow as when we run it manually. In what way are you recommending we look at the database?

Sorry by

The only Performance Boosters that matter are turning off progress bars and parallel server.

By Parallel Server I meant Number of Servers, MultiBshell, etc.

Dave

So you recommend to deactivate the table boosters and only keep the parallel servers active. Hmm.

I played with it quite a bit on my system - I increased the cached tables for MRP/MPS. I didn't see any remotely noticeable performance improvement


Dave