Is is feasible to put an HTTP cache in front of an OJS server?
Particularly, can I tell if someone is logged into OJS from the request, in order to bypass the cache?
Hi @Jim_Nicholls,
I’d suggest looking through lib/pkp/classes/core/PKPTemplateManager.inc.php
, which sets up the environment for delivering Smarty templates. There is some code there for configuring the HTTP cache headers with the intention of minimizing wasted traffic on certain pages. This could be extended to support instructions for a caching proxy – a simple policy, for example, would be to only send caching headers instructing the proxy to get active on higher-volume, rarely changing content (e.g. the Archives page, homepage, static content, etc).
But I would like to know a little more about your interest in adding a caching proxy. If you’re hitting a particular bottleneck, maybe it’s worth optimizing OJS first, and I might be able to help.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
I don’t have a performance issue per se.
I’m running OJS in containers. Local architecture rules dictate that I put the application behind a front. The front primarily provides a WAF. Secondarily it provides caching. I’m researching if there are opportunities to utilise that caching capability.
Thank you for pointing out PKPTemplateManager
. I’ll look into it.
Hi @Jim_Nicholls,
A WAF should already work just fine with OJS. But it won’t do a lot of caching, as OJS doesn’t (yet) provide much in the way of instructions via caching headers. This would be relatively easy work to improve, I think – but internally, the team is a little more focused on improving performance bottlenecks within OJS before we look to external tools. Let me know if you have any feedback/questions!
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher ,
Taking advantage of the topic, specifically for table of contents with many items, will it still be improved in relation to what we get after this issue?
It’s a bottleneck mainly for proceedings of conferences that are using OJS, but it also tends to affect more journals with the adoption of continuous publication with one issue per year.
Hi @abadan,
We’ve made a couple of improvements (as documented on that issue) that improve performance in later 3.3.0-x builds, and again in 3.4.0-x builds. But I think the most universal solution for very large tables of contents will be to use an object cache built into OJS, as most users will not be deploying behind a caching proxy.
Watch for some changes on Reconsider data caching mechanisms · Issue #7111 · pkp/pkp-lib · GitHub that will move this forward; it isn’t yet an object cache layer on published contents, but is a prerequisite for that work.
Regards,
Alec Smecher
Public Knowledge Project Team