Bitpoke App release 1.5
The Bitpoke App is designed to be a true auto-scaling and self-healing solution that can quickly scale and serve flawless WordPress publishing sites, learning platforms, and e-commerce shops.
Bearing in mind this goal, we’ve rolled up our sleeves and started working on the 1.5 release of the Bitpoke App.
Significant changes have been added to the core, bringing an important number of enhancements, new features, and bug fixes improving the DevOps experience and solution performance: page caching, cost estimation and optimization, marketplace deployment optimization, custom certificates setups, and ProxySQL tweaks.
The page caching mechanism
Page caching was on our shortlist of mandatory features when we looked for cost-effective solutions and tools that can be used and implemented in the App infrastructure to help our clients keep costs under control and improve their site performance.
We’ve investigated several cache mechanisms available on the market and we came to a simple conclusion: our clients deserve the best, so we decided to support both Memcached and Redis in our implementation, and ultimately it will be a user choice which one to use.
We’ve extended the well-written rtCamp’s https://wordpress.org/plugins/nginx-helper/ and included Memcached support. We’d have preferred to have our contribution included in the plugin, but were suggested to fork the project, which in retrospect was a good thing, since that allowed us to further customize the plugin.
The decision to implement a caching mechanism came as a conclusion that besides the native object caching solution provided by WordPress, we need something that can scale suitably when it comes to high demanding WordPress sites or WooCommerce shops with thousands of clients per second.
The latter needs a persistent file caching system beyond images and pages that can cache the backend properly.
The problem with the object caching WordPress built-in solution is that it isn’t persistent by default, which means the cached files and data are stored for a short period of time, no more than for a single page load.
This solution could be ineffective if your WordPress site is dynamic and loads a lot of data across pages, in this situation our recommendation is to take into consideration a persistent object caching mechanism that can speed up the WordPress page load times with each subsequent access.
The persistent caching mechanisms are based on the idea of caching once and served whenever needed, so the database queries are cached persistently between page loads.
These persistent caching tools are recommended if you are trying to scale your site or you have a lot of content. It will eliminate a lot of unnecessary load from your PHP server and your database nodes and can help to deliver a better and faster user experience and also it can help you reduce your costs effectively.
Coming back to our Bitpoke App solution, choosing between Memcached and Redis for your WordPress cache is a decision that must be made according to your needs, as long as the Backend field allows you to select between these two options.
However, it should be kept in mind that with Memcached there is no additional configuration required from your side. Everything is installed and configured in advance since it uses the same instance used for the WordPress Object Cache.
To use Redis instead, you should follow some prerequisite steps, such as deploying it and specifying its Host and Port in the configuration fields.
Three additional settings landed to the Page Caching tab and are marked as advanced settings for experienced users:
Cacheable Response Status Codes – allows you to specify which pages will be cached based on the response status code; Default TTL – this new feature allows you to set the default duration in seconds for which each page is kept in the cache before expiring; Honor bypass from response header – the toggle is on by default and it allows bypassing the cache when the Cache-Control or the Expires response headers specify so. For a more detailed explanation, you may consult our Page Caching documentation or the nginx config for page caching;
Thanks to this new feature, you won’t have to think about implementing your own caching system and the good news is that you don’t need to be a caching guru because the App does all the work for you.
If you’re not sure yet how this implementation works for you, we got to cover you with an easy step-by-step explanation to help you understand the whole mechanism of operation.
Let’s dive deeper into the demonstration and based on the following diagram, explain the Page caching infrastructure:
When a user accesses your site, the request is sent to the Load Balancer. From here the request is routed directly to the WordPress pods, where it interacts with the NGINX web server. If the page is already generated and cached the process is very straightforward, it will be fetched from mcrouter (which is the load balancer we use to scale Memcached) and the page is served directly to the end-user, provided it does not comply with a rule that bypasses the cache. If the page is not cached, the request will be handled as usual by the PHP server.
Price estimating made easy
We took cost optimization seriously, putting a lot of effort into developing a cost-effective system on top of Google Cloud that allows users to limit the cloud resources usage directly from the App, without sacrificing performance.
We’ve decided to add a transparent cost calculation system on our website and help our new clients to estimate the total cost of hosting on our platform. For a more comprehensive analysis of your potential architecture costs, you can use our revamped Bitpoke App price calculator where you can assess the estimated cost for your sites, according to your needs.
Custom certificates and ProxySQL configuration features from the command line
Starting with version 1.5, you’ll be able to set up a custom certificate for your site, if you wish to use your own certificate or if the deployment requires it.
In the previous article on launching Bitpoke App v1.4, we’ve mentioned that our platform already takes care of your Let’s Encrypt certificates. We are using Cert Manager to ensure that your default certificates are always valid and up to date.
But this new feature allows you to easily drop-in your own certificates directly from the command line. We know this feature is either not available at all with most managed WordPress hosting providers, either available with a high associated cost, or complex support interventions and interactions.
To make things easier for you, we’ve prepared a short how-to guide that will help you to configure your custom certificate if you need it.
Another feature added to this new release is the possibility to set up custom variables and rules in the ProxySQL configuration. Here you can find an entire tutorial about how to set up and configure custom variables.
We should mention that these new features are available only from the command line.
What’s coming up in 1.6
We are planning to build many useful features inspired by our customer requirements and by our vision of how a highly-available WordPress cloud-hosting platform should look.
The next major feature we’ve already started working on is a monitoring system integration, which will provide a clear vision of the system’s performance. We’re building this on top of Prometheus.
If our application caught your attention or maybe you have any specific requirements or questions about the implementation, you can book a demo with one of the Bitpoke App creators that can guide you through the way the App works.
To get in touch with our engineers, register on https://www.bitpoke.io/wordpress, or simply send us an e-mail at hello@bitpoke.io.
