Can you make OJS blazingly fast, like opening it on your local computer?
Our team in OJT can do that unbelievably well, even though we have released a free version plugin for you so you can also experience how fast your journal will become. This post is part of our research on improving the speed of OJS, read the first part: How to speed up 300% OJS
At openjournaltheme.com we also provide OJS Hosting services. With this OJS Hosting, all OJS functions, including plugins or themes that we have developed, can function optimally without exception. In the OJS Hosting Services that we provide, we have implemented various configurations that are able to meet the needs of OJS users optimally.
Back to the discussion of OJT Blazing Cache Plugin. This plugin can drastically improve the speed processing of the page in each of your journals by leveraging the smart cache in your journal. In our test case, we found 7.55 seconds of a journal response time to 287ms, yes you read that right microsecond (ms) after activating this plugin on the test page which means a more than 2500% improvement in a journal load in our test result.
Let us tell you a story about how it works and how we can do that.
Need better hosting that implements this improvement for your OJS? 👍
Check out our hosting package, which allows you to host and includes our expert team to support you in the technical aspect of your OJS.
Table of Contents
Background
Initially, we were aware that in OJS especially in the below 3.4 version of the OJS platform, there is poor usage of query that will negatively impact the site load due to many of the inefficient query. As we have explained and optimized before where we have improved the 300% OJS speed by leveraging the OJS Rocket.
Does OJS have a cache solution natively? at present, the web_cache feature in OJS operates below optimal performance as it solely caches static content. However, the most resource-intensive pages, including the front page, article details, issue list, and issue details, remain uncached. The genesis of this plugin lies in the recognition that queries generated by OJS are inefficient and verbose, placing significant strain on MySQL resources.
As we have been handling a server with very high traffic multi journal, even in a highly active OJS journal with 16 dedicated CPUs, CPU overload persists, triggering daily system overload notifications from our system.
Initially, we implemented an Nginx microcache to alleviate the overload issue. However, it became apparent that the feature encountered significant challenges with logged-in users and other dynamic pages. Furthermore, it lacked native web-based controls for cache clearance.
In response to these shortcomings, we set out to devise a mechanism for OJS to perform caching natively. We aim to develop a native and more friendly plugin for the dynamic creation and renewal of caching content triggered by changes to article details, frontend pages, and other elements. Additionally, it should be compatible with subscription-based (paid) journals.
Why does OJS need improvement?
OJS requires improvement due to performance issues, particularly in less or equal to version 3.3. Through our investigation, we discovered a significant number of inefficient queries that severely impact the speed of the OJS front page. This problem is particularly pronounced for journals hosted on OJS with a large number of submissions.
Technically, this issue is known as the N+1 problem. In database query optimization, the N+1 problem arises when an application executes N additional queries to retrieve related data for each of the original queries. In the context of OJS, this translates to excessive database queries being executed for each submission or item displayed on the front page, resulting in a considerable performance bottleneck.
This inefficiency leads to slower page load times, negatively impacting the user experience and potentially dissuading visitors from exploring further or engaging with the journal’s content which will poorly impact the journal citation.
The case of slowness was also worsened by the other plugin created by a third party that does not implement in detail the concept of efficient query. One of the plugins that we found is the Similar Article plugin which does the same inefficient query that made the load of the article detail page from < 2s (before plugin activation) to 10s (after plugin activation) or more (issue 8710) although the issue was closed. If you have used the plugin, we recommend upgrading it to the latest version.
At openjournaltheme.com, we provide OJS Hosting Service that can cover your various OJS needs. So you don’t need to worry about the performance of the server that we offer. In our OJS Hosting Service, there are various options such as adjusting the server location, computing power, to data backup, and others. So with our OJS Hosting you can get very optimal results for your OJS performance.
The other cause of OJS slow may caused by the third-party function that is included in the Scheduled Task feature in OJS that is internally built in the OJS and may arise from another plugin caused by a third-party developer. You never know after activating a plugin from the plugin gallery, the site become slower which will impact the visitor rate and the lower citation from the article. However, the plugin source is from the official plugin gallery in OJS.
The speed of the journal and article page that usually landed from the search engine is also crucial for the OJS site. Some of the considerations are:
- Site Engine Rank
Although the journal gains much indexing from reputable indexing, the most convenient way for an author to find the article is through a common search engine. There is a reason why Google takes> 90% market share for providing the query of user search globally. Google will reward any website that is faster as one of their ranking factor. To be a fast journal access performance means that your journal is one step ahead of another journal. - Potential Citation Loss
Many authors browsing for articles often rely on finding clues through convenient search engine platforms such as Google Search or other popular scholarly indexing services. However, when they encounter slow-loading pages upon accessing the site, it can significantly affect their mood and may lead them to subsequently leave the site without giving feedback to the journal manager. - Credibility of The Site
Slow access to a journal site will make a negative impression on the visitors that assume that the journal is not invested in a better infrastructure. This increase the confident from the journal to attract more potential quality author to your journal. - Indexing Review Process
As much of the indexing process involves manual review, assessing factors such as site uptime and availability is crucial. Sites experiencing issues with content loading may face delays in their indexing inclusion, as they are likely to be penalized for such problems.
What is our approach to improving the speed load in OJS ?
Improving by using Nginx Microcache
By acknowledging those issues, we are aware of the need for a caching mechanism. In our hosting platform, we leverage Nginx as our web server, and one of its standout features is the micro cache functionality which is exclusively only available in Nginx. Microcaching in Nginx enables the efficient caching of resources within a specified time range, offering advantages in terms of performance and server responsiveness.
Beforehand, we have made improvements to the speediness access of the OJS page by utilizing this feature as you can see in this article:
https://openjournaltheme.com/how-we-managed-to-optimize-ojs-frontend-for-almost-300-load-speed/
What is the problem with the Nginx microcache?
On the first attempt, we are happy to know that we can combine this server technology in providing this positive differentiate feature to our hosting client.
However, as the time goes by, the dissatisfaction and issue arise caused by the current limitation of microcache and need more than the result regarding some of the issues with the micro caching as we have used it in hosting infrastructure.
It’s crucial to acknowledge certain limitations associated with micro caching:
- Time Range Constraint
Microcaching operates within a defined time range. Resources are cached for a specific duration, and this constraint can impact the responsiveness to dynamic changes during that period. This means that when the time range of the cache is over, it will create the dynamic request again PHP and MySQL although there is no change in the OJS data modification.
So the cache is only valid for some specific range of time. We still consider that this is not a very good option for a caching mechanism. - Dynamic Content Issue
As previously highlighted, microcaching retains data for a specific period. Consider a scenario where a journal experiences high traffic, causing the micro cache to consistently provide content. In such instances, any modifications to the journal, website settings, or article metadata do not trigger a refresh in the caching mechanism. Consequently, visitors need to be served updated content.
For a journal, ensuring that any revisions promptly reflect in the public view is crucial. Unfortunately, due to the inherent limitation that PHP cannot directly natively communicate with Nginx, micro caching emerges as a suboptimal choice for Open Journal Systems (OJS). This communication barrier impedes the seamless update of cached content, making alternative caching strategies more suitable for OJS environments.
Microcache also ignores pages requiring authentication, such as those designated for subscribed-only access or paid articles. This is a crucial consideration when activating this caching mechanism. - Cache Invalidation
The importance of effective cache invalidation cannot be overstated in the context of Open Journal Systems (OJS). It is essential to guarantee that users consistently access the most up-to-date content following any changes within the journal. Successfully managing this process presents notable challenges, especially within the dynamic and content-rich environment typical of OJS where the publication of the article evolves the contribution and decision to many roles in the platform such as the reviewer, author, and editor.
To address these challenges, a nuanced understanding of the limitations associated with cache invalidation in microcaching is crucial. This comprehension empowers OJS administrators to adopt a more informed approach when implementing micro caching within the Nginx web server. Consideration should be given to the unique nature of scholarly content, the frequency of updates inherent in academic publications, and the specific hosting requirements of the OJS platform. - Webserver Compatibility
Using Nginx’s microcache for our caching needs faces limitations due to constraints within the web server application. Unfortunately, this caching mechanism is exclusive to Nginx and presents various challenges in ensuring compatibility with Open Journal Systems (OJS).
Moreover, configuring Nginx can pose difficulties for certain server administrators. Considering these challenges, there is a pressing need for a more user-friendly and readily adoptable caching solution to better serve our requirements.
The solution offered by OJS
The caching mechanism is already provided with additional configuration in the config.inc.php file. You can configure the OJS to store the static content such as the announcement, the static page, and another static page.
You can activate this feature by modifying the parameter in config.inc.php.
After configuring the caching mechanism, it’s crucial to establish a cron job to regularly delete cached data. However, it’s important to acknowledge that the caching mechanism in OJS is restricted to caching static content within the journal, including announcement pages and other static pages. This is even not includes caching for the most resource-intensive page such as the journal index page, article details, and another dynamic page. Additionally, this caching system operates globally, encompassing the entire journal. Implementing this is a bad idea for your journal. The configuration is also kinda complicated for a newbie because it needs to set up a cronjob to do a manual clearance of caching.
You might be wondering why changes made in the OJS backend, such as modifying the announcement page, aren’t reflected on the front page. This could be due to the caching mechanism, which waits for the cron job to execute and clear the cache before updates are visible.
Must have features of the speed improvement plugin
Based on our case studies of many of our clients, the feature of the caching plugin in OJS should fulfill the following requirements:
Dynamic Content Handling
The caching plugin should effectively handle dynamic content inherent in scholarly publications, ensuring that updates, revisions, and changes to articles, website settings, or metadata trigger timely cache invalidation.
Granular Cache Invalidation
Provide a mechanism for granular cache invalidation, allowing administrators to selectively refresh specific content or sections within the Open Journal Systems (OJS) platform without affecting the entire cache.
Never cache the logged page in OJS
The plugin is designed not to cache pages that require authentication, such as the login page and backend pages of OJS. This feature also ensures compatibility with subscribed-only (paid articles) pages, guaranteeing secure and seamless access for authorized users.
Empower the liberation of free caching
The plugin should provide journal administrators with the capability to manually clear the cache. In situations where certain activities require cache clearance but the plugin lacks an automatic mechanism, administrators can freely initiate cache clearing.
Introduction to the OJT Blazing Cache Plugin
After extensive research into available options and their limitations, we determined that developing a native solution within OJS was the best approach. Hence, we introduced OJT Blazing Cache, a plugin aimed at optimizing to the max of the caching mechanisms. OJT Blazing Cache intelligently stores server resource-intensive queries and processes as HTML files, resulting in a remarkable enhancement of journal access speed. This innovative optimization within OJS marks a significant advancement in performance improvement.
Furthermore, the plugin efficiently captures and stores content accessed by visitors or saved by administrators. It incorporates a Smart Cache feature that automatically updates cache content whenever changes are made to issues, articles, front page, or website settings.
Consequently, the stored caching system significantly reduces the need for repetitive processing of unchanged pages in the backend of OJS. This results in considerable savings in CPU and hardware resources. More comprehensive details on these savings will be elaborated upon in the benchmark section later on.
With the Smart Caching feature, this plugin will observe any activity that is required to renew the caching file in the notification area.
Status when the plugin recreates a new cache for the respective page.
The plugin also adds a signature to inform the status of caching.
How to get this OJT Blazing Cache?
In addition to providing OJS Hosting Services, we have also included OJT Blazing Cache in it. So if you use our OJS Hosting Service, then you will also get this OJT Blazing Cache for free while using this OJS Hosting Service.
Benchmark :
Enough of the talk, now we should provide how the plugin makes your journal blazingly fast.
In this test, we have deployed OJS based on our client data which has more and less than 100000 publisher articles since 1946. Here is the specification of the server :
Operating System : Ubuntu 20.02
CPU : AMD EPYC 7282 6 CPU cores.
Memory : 16 GB
OJS Version : 3.3.15
Nginx Webserver
PHP 7.4
Gzip Enabled
Mods Deflated Enabled
OJT Rocket Plugin installed
Method of benchmark:
We employ the browser console log to monitor the response time of each simulated page. This method is considered the most practical test as it allows users to directly experience performance improvement. The second test is to observe the daily monitoring before and after using the plugin.
Page : Index-Journal Page
Before activating the plugin:
After activating the plugin:
Now, to calculate the percentage difference between “7.55s” (before) and “741ms” (after):
Percentage difference = ((new value – old value) / old value) * 100%
= ((7550ms – 287ms) /287ms) * 100%
= (6809ms / 287ms) * 100%
= 2531%
Yes, it is crazy fast, just like the ping response, the site loads 2531% amazingly faster after using the OJT Blazing Cache!
This will be much faster if we access the site near the server location which is around the US network.
Need better hosting that implement this improvement for your OJS 👍.
Check our hosting package that allow you to host and include our expert team to support you in technical aspect of your OJS.
Article Detail Page :
https://monthlyreviewarchives.org/mr/article/view/6263
Before:
After:
Archive page :
https://monthlyreviewarchives.org/mr/issue/archive
Before:
After:
Conclusion
Indeed, our team has once again delivered exceptional results. The results achieved by our plugin, crafted with a blend of intensive research and innovative solutions, again speak fact, not fiction!
Just as an actor takes the stage, we stand before you to extend our heartfelt gratitude to our esteemed client. Their trust in us to understand and address their challenges has been invaluable for us to create a product that can be useful for the community.
Get The Plugin
Subscribe to get this Plugin and our product release!
Limitation
Although the most prominent advantage of this plugin makes your journal response time unbelievably fast, the cache file that is created by this plugin takes additional space to your server as it makes an HTML file for each of the content of your journal. For example one of the article detail pages taken from this journal create a HTML file for about 180KB for one file.
PS. We also create a free version for your journal, make sure you have added your email to our mailing list.
