Catch up on the conversation. This piece comes as a followup to our CEO Joshua Strebel’s recent piece on why you should never pay your WordPress host for pageviews. Managed WordPress hosting has exploded across the hosting industry since Pagely created it way back in 2006. Overall, the level of innovation that the mainstream has brought to WordPress is amazing. Unfortunately, this sometimes comes with negative side-effects. As investors demand higher profits, many of these managed WordPress hosts are looking for ways to gain a quick and easy boost to their margins. Like we mentioned in our definitive guide to PHP workers, there are a few different metrics that are often misinterpreted, whether intentionally or not. Today, we’re going to talk about pageviews and their role in the managed WordPress hosting world. What Counts as a Pageview? Many hosts cite pageviews as a billing metric with vague term descriptions, if any exist at all. Even with clarified definitions, pageviews tend to mutate on a host-by-host basis with a dizzying array of buzzwords. Although individual managed WordPress hosts vary on what they consider a “pageview”, most define it like this: pageviews are the number of unique IP addresses that access pages on your WordPress site per day, excluding known bots. (Yeah, I know. The term is more like “the number of unique request sources per day, based on predefined catch-all filters.” But I wasn’t the one that made this up, so bear with me here.) Pageviews as a Billing Metric Before we dig in any deeper into the details, let’s think about the definition that I mentioned. Considering that narrative, which of these sites would be more expensive to host? A directory website that houses billions of pages, showing 1,000 entries at a time. A personal blog who’s majority of traffic is to single posts. A documentation site where visitors typically access multiple pages per day. A simple informational website for a local restaurant. An online shop that sells small-batch artisanal snake oil. An API that uses headless WordPress to dynamically fetch content. If you guessed that they represent the same metrics in the eyes of pageview-based billing, your logic prevails! Assuming that they all experience the same number of unique visitors, they’re all treated the same way, regardless of how resource-intensive the site is or how many pages each visitor accesses. Of course, it would be silly to treat all of these sites the same way. Some pages might have large amounts of fully dynamic content, while others might be eternally served from cache. Using an umbrella term like pageviews as a billing metric causes several different issues, based on the site being hosted. Setting Realistic Expectations The first issue that pageview-based billing causes is an unrealistic expectation for low-performance, unoptimized sites. If you’re not familiar with how WordPress sites perform on the server side, you might think that these limits matter exclusively and use them to determine what capabilities you need from a hosting provider. If you’re evaluating your hosting options purely based on a pageview limit, you’re ignoring critical factors that can dramatically impact your WordPress site. Performance-Based Punishment What if you’ve put hard work into optimizing your site? Well, now you’re wasting money on a billing metric that doesn’t matter. If your site is highly cacheable, you’re feeling the impacts even further. When serving content from cache, it’s practically free from a hosting perspective. You’re being nickel-and-dimed for something that is entirely outside of your control. Knowledge is Power As you scale, knowing what you’re paying for can quickly become a critical part of maintaining a healthy, cost-effective site. Coupled with the fact that the same people who are charging for pageviews tend to hide their underlying infrastructure behind the curtains, there’s no way to verify or manipulate what’s being counted. While many claim that they exclude the known IP addresses and user agents of known bots from counting towards your monthly pageview bill, what’s their motivation for even bothering? After all, more pageviews mean more money in their pockets. Pageviews Are Still Helpful Many of our prospective customers ask, “How many pageviews can ‘x’ plan handle?” Like we mentioned earlier, the impact of each pageview dramatically varies based on the type of content viewed and how your site was developed. Every WordPress site is different. It would be impossible to accurately estimate the ideal hosting environment without a complete understanding of what your site’s usage looks like. Although pageviews are a faulty metric as far as billing is concerned, they can still be useful as part of a larger dataset. Whether you’re scaling, optimizing for better performance, or shopping for a new hosting provider, pageview data plays a role in getting a full picture of your site. For example, if you were running benchmarks to determine your server’s capacity, pageview data could be used to identify what a typical day looks like. Let’s say your site looks something like this: 10% of traffic is on the home page. 30% of traffic is to various landing pages. 30% of traffic is to different blog posts. 20% of traffic is to your product’s pricing page. 10% of traffic is on account-related pages. Using that traffic data, you could then estimate what types of content have the most significant impact on server resources. You may find that some pages underperform and could use some optimization, while other highly-cacheable content, like blog posts or landing pages, remain essentially free. If 90% of your traffic goes to fully-cached content, increases in traffic have a trivial impact on your bottom line, if any. Closing Remarks Operating a WordPress site at scale is all about a delicate balance of performance and cost. At Pagely, we partner with our clients to help them achieve those goals. While shopping for a new hosting provider, be on the lookout for hosts that impose false barriers, such as PHP worker limits and pageview counts. Those vague limitations are a red flag that they’re going to try to upsell you later. (These limitations are also a sign that they’re trying to sell you on shared hosting resources too, but that’s a topic for another discussion entirely.) We hope that you’ve learned more about the impact of pageviews (or lack thereof) and why it’s not an appropriate billing metric. Do you have any experiences with pageview-based billing that you’d like to share? Is there something we missed? Let us know in the comments below.
At Pagely, we pride ourselves on providing the best possible solutions for our customers. Sometimes, that requires dedicating a significant amount of research and development into truly discovering what works best. Whenever possible, we always want to take a data-backed approach. That’s why we’ve run several benchmarks to determine how PHP workers impact a site’s performance. By running these benchmarks, we can ensure that our customers can get the maximum amount of value out of their hosting environment. So without further ado, let’s take a look at our tests and what we found! Our Testing Environment First, let’s talk about the environment that we tested on. To ensure that our tests can be replicated and improved upon, we’ve performed them on a standard Amazon EC2 instance that anyone can spin up. In addition, we’ve also made the entirety of our benchmarking code available on GitHub. Our PHP Test Scripts As anyone who’s done any benchmarking knows, a primary concern is eliminating any potential noise within the tests. An excellent way of testing PHP worker behavior is to have the worker perform tasks that are heavy on CPU, without impacting things like disk I/O or network latency. To accurately benchmark PHP worker behavior, our test code is a simple PHP script that encrypts and decrypts a string several thousand times to perform CPU-heavy activity. Here’s the gist of how it works: // Encrypt and decrypt a string 50,000 times. while ( $times_run < 50000 ) { $encrypted = openssl_encrypt( $string, $method, $key, null, $iv ); $decrypted = openssl_decrypt( $encrypted, $method, $key, null, $iv ); $times_run++; } Our Benchmarking Environment On the client-side, we wanted to ensure that we’ve eliminated noise from any outbound requests, while performing tests that accurately reflect different CPU core counts. For this, we wrote up a shell script that runs the k6 benchmarking tool against various Docker container configurations that reside on the server. By using Docker, we’re able to run a single script that utilizes different numbers of CPU cores and runs benchmarks against each separate core count. Just like our PHP code, it also resides within GitHub for you to take a look through. Here’s how we’re doing it: #!/bin/bash mkdir -p reports # “num-cores cpuset” for row in “1 0” “2 0-1” do set — $row cores=$1 cpuset=$2 for worker in {1,2,8,50,100,200} do pworker=$(printf “%03d” $worker) pcores=$(printf “%02d” $cores) file=reports/${pcores}core-${pworker}worker.txt json=reports/${pcores}core-${pworker}worker.json if [[ ! -f $file ]] then ./run-php.sh $cpuset $worker $file ./run-bench.sh 3 $worker $json >> $file fi done done Our Results When processing our results, we need to eliminate things like network latency. Thanks to the k6 benchmarking tool, we were able to do that with ease by looking at http_req_waiting times and using the following statistics: Average response time Minimum response time Median response time Maximum response time p90 (maximum response time for the fastest 90% of users) p95 (maximum response time for the fastest 95% of users) Requests per second Requests Per Second Within our tests, we’re sending a number of virtual users that match the number of cores being utilized by our testing environment. For example, when running a test against an environment with 4 CPU cores, our benchmark uses 4 simultaneous virtual users. These users perform a request, wait for a response, then immediately send another request. They’ll continue doing this for our testing duration of 60 seconds. Here’s a graph of the results: As you can see, a balance of PHP workers and CPU cores is what matters most. Without enough dedicated CPU workers to handle the influx of traffic, requests can’t be handled efficiently. In contrast, after a certain point, adding more PHP workers has a minimal impact on the number of requests per second that the server can handle. Once at critical mass, there’s even a negative impact on the site’s performance as too many PHP workers are added. Looking even further at the data we’ve collected, we can quickly determine that the optimal number of PHP workers varies based on the number of CPU cores being utilized. Of course, on different workloads (different levels of code optimization) or digging deeper into different PHP worker counts, we may have found a slightly more optimal worker pool. Still, overall, it’s a pretty good starting point. Looking deeper into how the number of PHP workers impacts the number of requests per second that our test environment could handle, we see some interesting data. For example, let’s look at our 32 core test: 1 Worker 4.99999187 2 Workers 10.86665914 8 Workers 41.84993377 50 Workers 160.8998032 100 Workers 162.8164824 200 Workers 160.1164952 400 Workers 159.6665389 As you can see here, the number of requests per second that can be handled steadily increases as we increase the PHP workers, until it reaches 50 workers. At 100 PHP workers, we see a slight increase; then, at 200 and 400 workers, we see performance declining. This is a common trend amongst all of our tests. After a certain point, adding more PHP workers will decrease performance overall. While the impact is at rather low levels, this can be majorly problematic for sites that don’t have a dedicated resource pool. Many shared/cloud WordPress hosts have thousands of people all on the same server. Since the number of PHP workers will need to be significant (and they’re always screaming about how many PHP workers they have), every site on the server is negatively impacted by the worker pool as a whole. Measuring Response Times While the overall capacity of requests per second is a reasonable determination of how many users a site can support simultaneously, it’s not the only metric at play here. In our tests, we also measured response times, based on the number of PHP workers are active for environments with different core counts. Here’s what our chart for a 32-core environment looks like: As you see here, there is a measurable increase in response times as the number of PHP workers increases. While our Requests Per Second statistics only change slightly between 50 PHP workers and 400 PHP workers, request time shows an entirely different story. Let’s take a look at the raw data to look a bit closer at what’s happening: Worker Count Average Minimum Maximum Requests Per Second 1 Workers 199.39 198.50 208.07 4.99 2 Workers 183.67 177.27 188.35 10.86 8 Workers 190.71 175.81 197.59 41.84 50 Workers 309.70 189.69 1034.55 160.89 100 Workers 610.20 191.03 2903.50 162.81 200 Workers 1230.40 194.00 3937.65 160.116 400 Workers 2422.41 197.82 10478.34 159.66 When running a static count of 50 PHP workers across 32 cores, we see that we can make 160 requests per second, with an average response time of 309ms. When we increase that worker pool to 100 PHP workers, we see that we can handle an additional 2 requests per second, but our average response time increases to 610ms. That’s a 97% increase in the time it takes PHP to handle the request for only being able to handle an additional 1.25% more users! As we increase the worker count even further, we see that while the number of requests per second stays roughly the same between 50 and 200 PHP workers, our average response time increased by almost 300%. From this data, we also see that while a lower number of PHP workers in the pool can handle less traffic, our response times do become lower. At 8 PHP workers, we’re only able to process roughly 41 requests per second, but our site became much faster — responding in around 190ms. Putting It All Together After running our various benchmarks, we see plenty of interesting data that everyone can use to optimize their WordPress sites better. Within our benchmarks, we’ve proven that the number of available PHP workers on your server does indeed matter quite a bit — just not how you might have imagined. Now that you’ve seen the data, we’d also like to stress the importance of running an optimal number of PHP workers that is appropriate for your WordPress site, rather than just guessing or taking a cookie-cutter approach. More PHP workers do not necessarily mean increased performance. If not tuned to the exact specifications of your site, changing your PHP worker count can be catastrophic to your site. If you’re attempting to tune your site’s performance to handle more traffic or get faster page load times, you’ll want to do so in a way that’s specific to your website and the server on which it resides. Generally speaking, if you want to increase the number of users that your site can handle simultaneously, you’ll want to increase your PHP worker count. If you want your site to be faster, decrease the worker count. If you want a mix of the two, you can always use dynamic limits with a minimum and maximum worker count. Having a dynamic worker count allows you to handle spikes in traffic while offering faster page load times when you’re receiving an average amount of traffic. Want to share your thoughts? Have an idea for performing even better tests? Want to see something else benchmarked? Let us know in the comments below.
Thanks to 1-click installers and GUIs, WordPress exists as a way for people to quickly get things done, many times without a deep understanding of how all of the pieces fit together. WordPress’s ease-of-use is a great thing, but it can also leave many people in the dark when it comes to scalable approaches and best practices. Several service providers try to solve this problem by offering a “1 size fits all” approach. While a generic way of doing things might work alright at first, you’ll likely find out down the road that you lack the customization to scale based on your site’s needs. Is the solution to do everything yourself without any guidance? Unless you have a full team of extremely talented people working around the clock to manage your sites, you’re likely to run into even more problems as things complexities increase with scale. So what do you do? Here at Pagely, we realize that scalable solutions can sometimes be a significant change from what you and your team are used to. You’ve likely moved up to Pagely from a generic, cookie-cutter approach, but now it’s time for the big leagues. To help ease that transition, we want to help you gain a full understanding of how the Pagely stack operates, the tools that are at your disposal, and best practices when developing or deploying your WordPress site. Announcing Pagely Quickstart Today, we’re proud to announce the Pagely Quickstart education center. Inside Pagely Quickstart, you’ll be able to walk through every aspect of what you’ll need to know when onboarding with Pagely. We’ve covered everything from logging into our Atomic control panel to creating automatic deployments across multiple environments. Since we realize that your time is valuable, Pagely Quickstart is broken up into several different courses to keep your learning experience quick and lean. Are you an account owner who wants to let their development team handle the heavy lifting? Do you want to give your developers a course to help them hit the ground running? Each course is designed to be as efficient as possible. Nobody likes to be bored with endless information that they’ll never use in a practical scenario. Pagely Quickstart Includes Comprehensive Product Guides for our Proprietary Technology & Service: The Atomic Control Panel Overview Migrating to Pagely Gaining SSH/SFTP Access Installing SSL Certificates ARES, PressARMOR, PressCACHE, PressCDN, and PressTHUMB We hope that you’ll find our new Pagely Quickstart courses useful. As we move forward and collect feedback, we’ll be adding further enhancements to ensure that your learning experience is comprehensive and enjoyable. If you have any feedback for us, feel free to let us know in the comments below!
One of the greatest things about WordPress is the open source community behind it. Thanks to the multitude of plugins and themes available, even the most basic of users can create and deploy a WordPress site with ease. Through this beautiful ecosystem that empowers people to build amazing websites, several businesses have also flourished. Premium plugins like Gravity Forms and Easy Digital Downloads have even created niche communities inside the broader WordPress community. The Benefits and Drawbacks of WordPress’ Open Source Ecosystem WordPress itself is available under the GPL license. Although hotly debated and rarely enforced, this means that the PHP code inside of any WordPress plugins and themes must also be licensed under the GPL. Because of this, even premium plugins and themes are usually released under the GPL license and can be legally distributed to anyone who wants them. Not only does the license allow someone to give these premium products away for free, but anyone can even resell them without permission. As an advocate for open source software and someone who has contributed countless hours of his time to giving back to the WordPress community, I love this approach. Almost everyone in the world uses some form of open source software to improve their lives, so why not give back as much as possible to improve someone else’s life? But inside the WordPress ecosystem (and many other open source platforms), there’s a problem with this approach that can’t be easily solved. Scavengers all over the world abuse the generosity of the open source community by exploiting the freedoms that they’ve been offered. They’re not just impacting those WordPress-based product businesses — they’re hurting the end-user. 3rd-Party WordPress Product Resellers Reselling 3rd-party WordPress plugins and themes is quite common and easy to do. It’s as simple as getting a copy of the product, setting up a website, then offering 90% off of whatever price that the creator is charging. It takes minimal effort, if really any at all. If you’re the average small business who built your own WordPress site, you probably wouldn’t even know the difference. Isn’t it still the same plugin? The important thing to note is that most premium WordPress plugins and themes aren’t selling you their code or access to a download link. They’re selling a license for support, updates, add-ons, and various other perks. When it comes down to it, you’re buying into a guarantee that you’re receiving a quality product from a reputable brand. Unfortunately, a typical small business wouldn’t notice this distinction. When problems arise, such as compatibility or security concerns, who do they go to? If they received the product from a reseller, is the reseller going to make sure that they’re in good hands? Most certainly not. Nulled WordPress Plugins and Themes Even more dangerous than buying a WordPress plugin or theme from a 3rd-party reseller is getting a free or “nulled” copy. For those who might not be aware of what a nulled product is, it’s a premium product that has had its licensing stripped out so that it can be used without any sort of validation that the product has been purchased. Why would someone go through the trouble of doing something like this? There are somewhat rare instances when it’s done for philosophical reasons, but in the overwhelming majority of situations, it’s to exploit the user. Sometimes these “nulled” versions will collect some data from you. Other times, they might collect data about your site. Worst of all, they might completely infect your site and users with dangerous malware. In fact, malware infections are quite common amongst unlicensed premium plugins and themes. For example, the WP-VCD malware has been spread exclusively through nulled plugins and themes. Once a site is infected, the plugin will call home to receive instructions on what to do with its newest victim. Usually, this will include hiding spam links on your site, as well as creating a new admin user. It’s pretty nasty stuff. To read more, check out Wordfence’s full report. Limiting Risk and Avoiding Dangerous Software You’ll never be able to completely prevent 100% of issues as long as you’re running 3rd-party code. Still, you can dramatically reduce your risk by always using reputable plugins and themes that come directly from the author. In general, evaluating any plugins or themes with the following criteria will dramatically reduce your risk: Is the product widely used? Is the product actively maintained? When was the last update? Have there been any security issues in the past? How quickly were they resolved? Is the product being purchased and downloaded from the original author? If you have a developer on staff, it never hurts to have them perform an audit of any changes that happen on your site. If you’re installing a new plugin, it’s always a great idea to take a look through the code that it’s running. If it’s a well-known plugin with a good reputation, you’re almost always safe, but the extra bit of verification can go a long way to keep you secure. You’ll also want to check with your WordPress hosting provider to make sure that they’re actively protecting you from any known (or even unknown) threats that your site may face. Any reputable web host will have a security staff that is actively protecting your site. Most of the time, they can identify an issue extremely quickly and resolve it before you even knew it existed. Remember when I mentioned earlier that buying a license for a premium WordPress product was much more about buying support, updates, and a guarantee of quality? Don’t forget to take advantage of those perks! If you have a concern, get in contact with the author for help. After all, that’s what you paid for. With a bit of honesty, integrity, and knowledge, avoiding dangerous WordPress plugins and themes is quite easy. If you have any questions or tips that would help others, feel free to drop a comment on this post. We’d love to hear your thoughts.
Whether you’re running a single WordPress site or a million, you’ve likely come across this question at least once: how do I scale as I grow? It’s a tough question to face. Should you scale up to a larger server, scale horizontally to additional servers, or is there something else that you should do instead? In this article, we’ll take a look at the different scenarios to help you determine which is best for scaling your site. Determining Needs When it comes to scaling WordPress sites, there isn’t a 1-size-fits-all answer. Your business is unique, and your website is no different. Even if your site was built exactly like another, you might not have the same goals in mind. Due to all of these variables, what works for one business may not work for another. There’s a well-known saying in most industries that you can have it 2 of 3 ways: good, fast, or cheap. It’s no different when it comes to hosting your website. If you’ve kept costs as low as possible and have done the right performance enhancements that your site needs, you might be barely skating by on your server’s resources. What if you wanted the fastest possible site and are willing to spend the money to ensure that nothing ever goes wrong? In many cases, there’s still a performance impact, even if a small one. So, where do you even start? Let’s take a look at a few things to consider when determining how to scale your WordPress site. Reliability How critical is reliability to you? If your site were to go down for 5 minutes on a Tuesday afternoon, how would it impact your business as a whole? Would you even notice? In a perfect world, every site would be up and running 24/7. While you might want to guarantee that your website would stay up and running smoothly forever, even in the face of catastrophe, it most certainly wouldn’t be cost-effective or practical. Even the biggest companies in the world, such as Amazon or Google, have issues from time to time. It’s just the nature of the beast. When determining how to scale your WordPress site, it’s essential to set realistic goals that reflect your needs. If you’re running a local restaurant or any other company that does the overwhelming majority of its business in person, a flawless uptime record might not be your highest priority. In contrast, if you’re operating an online-only eCommerce business, any sort of downtime could be detrimental to your bottom-line. It’s also important to keep in mind that running a reliable site is much more than how you host it. Things like hardware failures are exceedingly rare, thanks to advances in modern technology. In the overwhelming majority of cases, reliability boils down to how updates are performed, how well your code is written, and a multitude of other factors. When you’re determining your reliability needs, be sure to consider the fact that server reliability can be impacted by far more than server size or quantity when deciding how to scale your site. When reliability isn’t a critical concern, vertically scaling up to a larger server is usually your best option. It’ll allow you to keep costs lower than having multiple servers and handles future growth by accounting for higher resource usage when traffic grows. The downside is that if that single server goes down, everything else is going down along with it. If reliability is vital to your business, horizontal scaling is the best option. By scaling out horizontally, you’ll be balancing resources across multiple servers. If a node has an issue, another node is still there to handle your traffic. Performance We all want our sites to be fast, but how fast is enough? Are you concerned about a few extra milliseconds on the occasional page load? Perhaps the most important thing to understand about website performance is that it’s not all about the typical “page load time” metric that most people realize. When considering server performance, it’s not about how quickly a page can be served up, but rather how the server handles all of your traffic as a whole. If your site’s traffic increased by 50%, would your page load time remain the same? Aside from things like a gateway layer to handle horizontal scaling, you’ll need to figure out how your files will be handled. You’ll need to have a process in place to sync data across all of the servers. Not only will it take additional configuration to accomplish, but there can also be increased performance impacts if files or databases need to sync up often. The performance impact of scaling out to multiple servers can largely depend on your team that’s managing those servers. If you have a configuration that’s highly-optimized for how your site operates, those performance impacts can be minimal. When determining the best way for you to scale your WordPress site, here’s what you’ll want to consider: If you’re not as concerned with performance as you are reliability or cost, scaling out can be your best option here. On the flip side, if performance is your biggest concern, you may want to opt for scaling up to a larger server. Of course, if you have the funds to have a great team managing your servers, you’ll likely be able to scale out to multiple servers with a minimal impact on performance. Cost If you’re scaling your WordPress site, another thing you’ll want to consider is cost. Are you a small startup that’s trying to save money wherever you can? Are you an established business that has a larger budget? How much is your website worth to your business as a whole? Just like any other business asset, the better your team is, the better your end-results are. Great teams typically cost more, and it’s up to you to determine how much you’re willing to spend. If you have a small group with a lower budget, it might be best to scale up instead of out. As we mentioned earlier, scaling out to additional servers requires more advanced configurations that are custom-tailored to your site based on your needs. Due to these more complex configurations, your team needs more expertise and monitoring capabilities. Scaling up to a larger server is also a better option if you want “more bang for your buck.” Upgrading an existing server to allocate more resources is almost always cheaper than adding a second server for balancing resources. Hosting Multiple Sites: Evaluating Blast Radius Now that you have an understanding of the different things you’ll need to consider when deciding how to scale your WordPress site, let’s look at an additional scenario that might also apply to you: blast radius when hosting multiple sites. If you’re a WordPress agency who’s also hosting sites for your clients, or even hosting multiple websites for your own business, you’ll want to take further considerations in regards to blast radius. Your site’s blast radius determines how far an issue can reach. Does a problem with one site become an issue for others? For example, if you have multiple sites and one site decides that it wants to use up all of the available resources or became the target of an attack, it can cause the others to go down as well. If you’re hosting lots of little non-critical sites, some downtime might not be as much of a problem, but if you’re going to get a bunch of phone calls as soon as a client’s website becomes unavailable, you’ll want to limit your blast radius as much as possible. Scaling horizontally to additional servers is an excellent way to avoid problems with resource spikes. If a site starts spiking in traffic, server resources have a way to spread out. Going even further, if your entire fleet of servers is hitting capacity, you can easily add additional servers to handle the load relatively quickly. Beyond Hardware If you’re increasing in resource usage, you might not even need to add more hardware. Often, it’s something as simple as optimizing your WordPress site or server. Making sure that your code runs as smoothly as possible is a great start. By understanding your site’s performance as a whole, you’ll be able to make better decisions that could save you quite a bit of that hard-earned money. Even if you don’t have a dedicated development team working on your site, hiring a good freelance developer or agency to perform a few performance enhancements can save you a ton of money in the long run. Having an experienced team to manage your servers can also have an astronomical impact. An elite group of talented people can identify those opportunities and provide creative solutions to squeeze even more performance out of your existing setup. Frequently, these enhancements have a minimum impact on your budget, if any impact at all. So How Should I Scale My WordPress Site? Every site is unique, and there isn’t a simple answer to how to scale every WordPress site. It’s all going to depend on what’s essential to your business. Are you looking for more performance? Better reliability? The cheapest possible route to handle growth? If you’re looking for better reliability, your best option is usually to add more servers and scale horizontally. When trying to get the most out of your investment, scaling vertically to a larger server is going to be your best option. If you need increased performance, you’ll want to take a look at how your code is performing (and if all else fails, jump to a bigger server). Of course, these are all general rules. Determining how to scale your site is much more complicated than what could be written in an article or even an entire book. The complexities involved with scaling WordPress sites are best handled by always having an experienced team in your corner. If you’re not an expert in scaling sites, your best asset is someone who fully understands how your website runs and can provide deep insight on how to grow it. Need a team of WordPress experts to have your back? Pagely is always here to help your business grow.
We’re excited to announce that our development team has several new Atomic features that they’ve been working so hard on! Without further ado, let’s take a look at what we’ve rolled out in the newest version of the Atomic control panel. Simple Path Redirects Previously, the process of creating a redirect would have required a WordPress plugin, changes to .htaccess files if in Apache+NGINX mode, or contacting support for them to create a gateway-level redirect for you. Today, we’re proud to announce a new feature for managing redirects. Within each app, you can now create gateway-level redirects with ease. To check out the new redirect feature, jump over to your app’s settings and look for the new Custom Redirects section, or check out our documentation on creating custom redirects. Moving Domains Between Apps Have you ever needed to transfer a domain or domain alias from one app to another? Now you can do it from inside Atomic with just the click of a button! For more information on this new feature, please take a look at our documentation article on moving domains between apps. Easy Billing Cycle Changes At Pagely, we pride ourselves in being a flexible solution that best fits the needs of our clients. The flexibility of Pagely includes not only meeting the needs of your technical departments but also your accounting needs as well. That’s why we’ve rolled out a new feature that allows you to easily change your billing cycle from directly within the Atomic control panel. Billing cycles can easily be adjusted between monthly, quarterly, or annually with just a click of a button. For more information, see our documentation on changing your billing cycle in Atomic. A Focus on Education As you may have already heard, we’ve recently added Jeff Matson to our team of experts here at Pagely. Since he came on board three months ago, he’s been working hard to do what he does best: provide outstanding customer experiences through education. (He’s also pretty good at describing himself in the third person when writing blog posts.) With Jeff at the forefront of Pagely’s documentation efforts, he’s also leading an effort in improving user experience inside Atomic. One of these efforts that has rolled out is better descriptions of roles when adding a new collaborator. While these roles have always been described inside Pagely’s documentation, we wanted to make it even easier to understand the role you’re selecting, without the need to review an article on our documentation site. The addition of collaborator role descriptions is just one of the many new changes that we’re building into Atomic that focus on saving you time and effort while giving you a better understanding of our systems as a whole. We Love Your Feedback! Is there a feature that you would love to see? Are you excited about this new update? Let us know in the comments below or connect with us on Twitter.
