I have fasthpath installed and it’s doing a bang up job, reducing CPU around 25 - 30%. I have now purchased adabas cache, but I’m in the middle of a fight over disk space, i.e. I can’t get any more.
I have 300M of allocated memory for fastpath, which by the end of the week (IPL each week) is 95% full. I’m thinking of taking 100M of this buffer out and put it into adabas cache to cache some files that that are used a lot, but fastpath cannot get for various reasons: see stats below:
Adabas Cache is primarily an I/O saver while Fastpath is primarily a CPU saver, but might also save I/O by holding data in memory.
In this sense both products complement each other.
I do not understand what you mean by lack of disk space, because neither Adabas Cache nor Fastpath need substantial amount of disk space.
Assuming you are on z/OS, Fastpath needs room in the ECSA, which is virtual storage and may be limited, but Adabas Cache can and should use preferably storage above the bar (which is virtual 64) or could use its own data spaces. Adabas Cache is not allocated out of the ECSA
So there should be no conflict unless you are severely constrained by lack of real main memory, which is rare nowadays. If this is the case I suggest you do not use Adabas Cache until you get more real memory on the system.
For Adabas Cache to be effective as an I/O saver you usually need more memory than for Fastpath.
My shop has all sorts of weird and wonderful rules, and since I’m a very little fish in a very big pond, getting any extra resources is extremely dificult, even above the bar.
I agree with Rainer, Fastpath and ADACache are different and complementary. I also agree that they use different system resources. Fastpath uses ECSA; ADACache usually uses the 64-bit area these days.
Both products cache data, in different ways.
Fastpath caches outside of Adabas. Therefore the data it caches is decompressed; it has already been through all the format translation, decompression, IO, thread-scheduling, ADACache, etc processing. Therefore any element cached by Fastpath, and then reused to service another command gives a vast amount of savings, nsmely all of the processing I mentioned already. This is a very positive return from the Fastpath cache (called optimization). This is high-value cache usage. Think of Fastpath as the front-line cache, if it services a command things are really great. But Fastpath can’t do everything, some things have to fall through to Adabas of course.
The remaining commands (traffic) that hit Adabas can then be made more efficient if ADACache can service IO requests rather than going to disk. This is a back-end cache; as Rainer says it saves IO. Anything ADACache saves still has to go through decompression, format translation etc. And again Rainer is correct, ADACache will be much more likely to use greater amounts of different resource; so if real memory is short then it will potentially contribute to paging. So real-memory is the first thing to make available, but not by reducing the different resources used by Fastpath.