This week on the podcast, Kyle shares his thoughts on apply CPU vs. PSU java patches and Dan explains the different options for preloading application server cache.
- Shard Planning for Petabyte Scale Elasticsearch Clusters @ 3:50
- Customizing the Homepage @ 5:30
- JDK even v. odd number releases @ 13:00
- PeopleTools Security Patching @ 19:30
- Preload Cache @ 26:00
3 thoughts on “#160 – Preloading Cache”
Thank you for going over the different options for preloading application server cache, this was very helpful!
I am already beginning to test out the shared cache method and I am blown away by the difference in performance. In regards to keeping this cache updated after migrations, did you need to bounce the application server domains so they recognize the new cache files?
We haven’t bounce the app servers after building the new shared cache files. Our batch job has a script at the end to copy the new cache files from the
STAGEfolder to the
SHAREfolder and we don’t restart the app servers. You’ll want to make sure that’s the case for you. It should be easy to test and verify on your end.
Another trick is to do full cache load once, distribute cache files, but then leave the appserver set for doing normal cache activity. This will allow each PSAPPSRV to load new objects as they change, while having the full base set. This might be a strategy for running full load once/wk or once/month and letting the system update by process for any migrations in between.