VPS Server Visitor Capacity and Temporary Resize FAQs

Note: This article is for our customers on a VBURST-2 or higher plan. We do not support temporary resizes on our shared cluster. For shared customers, you must upgrade your plan as needed.

We understand you may need a bit more resources to handle really big bursts on traffic on certain days and Pagely can help you scale your server to accommodate those busy days!

For temporary server resizes, we require the following:

• At least 1 hour notice notice for a scheduled resize during business hours.
• There is a 1 week minimum for any temporary resize.
• Pricing is subjective to your current plan and desired resize. Please contact support for correct pricing.

Before considering a temporary resize, we highly advise you to ensure that your site is well optimized to avoid any server instability.

How Many Concurrent Users Could We Support on 1 Site?

This depends highly on the type of traffic and whether or not it can be cached.

Each site has a dedicated number of PHP workers which are utilized for any dynamic content. However, any content that is cacheable will be served by NGINX directly and won't invoke any PHP workers. Common causes of PHP worker usage are logged in users, cache misses, POST requests to admin-ajax.php from the frontend of the site for things like view counters, etc. However, a well caching site can handle thousands of requests per minute.

How Is Resizing Handled? If Required, Can Pagely Resize on the Fly Without Interruption to Service?

Pagely can resize your servers with a lead time of about 1 hour during normal business hours. In the case of emergencies requiring a server resize, this can be done on much shorter notice as long as you pre-authorize the scale-up charges for such an event.

A resize requires taking the server(s) down very briefly (less than 5 minutes) to change the instance type and start it back up. There is no IP change nor data loss associated with this event.

Typically, a temporary resize has a 1-week minimum length. Pricing varies based on the current subscription type and the size you desire to scale up to.

In a HA configuration, downtime is very minimal or nonexistent for people browsing the front-end of site, with only a brief interruption of less than 5 minutes to the /wp-admin/ URLs.

If you have an expected spike in traffic and want to pro-actively resize the server(s), please contact support!

How Is Load Handled for Clients?

The biggest advantage you have for scalability is for your sites to cache as much as possible.

NGINX's full page caching feature is extremely powerful and can increase throughput by 2 or more orders of magnitude.

For example, a site that is not caching well could handle maybe 25-100 requests per second at the most. Conversely, a site with a good cache hit rate can handle upwards of 1000-3000 requests per second or more.

In addition to NGINX page caching, Redis Object caching can help speed up dynamic page times as it reduces the number of calls that have to be made to the MySQL database and can read transients from an in-memory object cache based on Redis. We can enable this on any site.

This support article should help you optimize your site: Optimizing Your WordPress Site With Pagely