Assessing Memory and PHP Worker Resources

Staq’s robust infrastructure ensures that 95% of hosted sites perform optimally without exceeding their base plans. This is achieved through our decoupled environment, which operates as a Virtual Private Cloud Network leveraging various AWS services. This pooled resource model provides additional power compared to traditional hosting solutions.

Below are instructions on assessing your site’s performance and determining whether additional resources are required.

Sections Covered:

• Visitors
• Data Storage
• Database Storage
• Bandwidth
• CPU Usage
• Memory
• PHP Workers

Automatic Scaling of Some Resources

As a cloud-based AWS WordPress hosting platform, Staq’s infrastructure automatically scales the following resources:

• Visitors
• Data Storage
• Database Storage
• Bandwidth
• CPU Usage

If any of these resources are exceeded, you will be notified via the dashboard and email alerts. Learn more about managing overages in our guide.

Key Notes:

1. There is no need to upgrade plans manually. Staq operates on a pay-per-usage model for these resources.
2. If you prefer a fixed-price plan, contact support for assistance.
3. For strategies to optimize costs, refer to our cost optimization guide.

For high-demand websites, Enterprise plans are available. Contact support to learn more.

Assessing Memory and PHP Worker Resources

Accessing the PHP Worker Statistics:

1. Navigate to the site’s Staq Panel.
2. Click on PHP Workers.

Analyze Data Based on Timeframes:

• Hourly Analysis: Best for troubleshooting immediate issues.
  • Timeframes: 3, 6, or 12 hours.
• Daily Analysis: Provides an overview of the site’s health.
  • Timeframes: 1, 3, 7, or 30 days.

Metrics available for analysis include:

• CPU
• Memory
• Requests
• PHP Workers
• Parallel PHP Workers

Key Metrics and Their Implications

CPU Usage

• Total Requests Duration: Time spent handling all incoming requests.
• Requests CPU Time: Active CPU time for processing requests.

Memory Usage

• Max Memory Usage: Peak memory used during the selected timeframe.

This metric helps identify:

• Whether the server has sufficient memory for its workload.
• If there are memory leaks or excessive memory consumption by processes.

Requests

• Total Requests: Total HTTP requests handled within the timeframe.

This metric helps in:

• Understanding traffic patterns for surges or anomalies.
• Monitoring overall application usage.

PHP Workers

• Total PHP Workers: Tracks active PHP processes.

Parallel PHP Workers

• Max Parallel Workers: Maximum concurrent PHP processes.
• Average Parallel Workers: Average concurrency.

Reviewing Real Data and Analyzing Spikes

Let’s look at a real example to demonstrate how to analyze resource usage and decide on appropriate actions. In this case, the website is on a base plan with 10 PHP Workers.

Example Analysis

At UTC time 23:00 (11:00 PM), resource usage spiked significantly. Here’s how we analyzed each metric:

CPU Usage

The CPU usage spiked at 23:00, indicating heavy server demand. This is usually caused by high user activity or resource-intensive operations, such as preloading pages or running background tasks.

Memory Usage

Despite the CPU spike, memory usage remained stable. This indicates that the operations during the spike were CPU-intensive rather than memory-heavy.

Requests

The total number of requests surged during the same period, aligning with the CPU spike. It’s important to note that static assets and cached requests handled by Nginx do not pass through the PHP context, so this increase likely reflects PHP-intensive activities such as dynamic page rendering, database queries, automated tasks (e.g., page preloading), or a logged-in user performing extensive operations.

PHP Workers

PHP Workers were utilized steadily and reached their peak capacity of 10 workers during the spike. This indicates that all available workers were in use to handle the incoming requests.

Parallel PHP Workers

The Parallel PHP Workers graph shows that the average worker usage during the spike was 2.27 but hit the configured maximum of 10 workers. This suggests the server reached its concurrency limits. The only way to increase this is configure the PHP Config inside Staq Panel for this particular site.

Identifying the Cause

There are two ways to identify the cause of resource spikes:

1. Assessing Server Raw Logs

If you prefer to investigate using server logs, you can download the raw logs, such as PHP-FPM Access logs, for detailed insights. Refer to our guide on retrieving server logs for step-by-step instructions.

2. Using the Firewall Reports

Alternatively, you can analyze activity using Staq Firewall Reports:

• Log into the site and navigate to Staq Hosting > Firewall > Reports.
• Select the date and time range around the spike. For example, choose a window 5 minutes before and after the spike.
• Click Generate Report to view detailed request logs.

In the generated report, you can identify the IPs responsible for the increased resource usage. In this instance:

• The server Ip was identified as using alot of resources. Upon further review, it was NitroPack generating preloaded cache pages.
• An IP associated with a logged-in user performing extensive actions on the website.

It may differ for you but analyzing these logs can help pinpoint the exact cause and guide the next steps in resource optimization.

Recommendations

Based on the analysis:

• Replace Preloading Plugins: Switching from NitroPack to Staq Cache would reduce resource strain, as Staq Cache preloads pages more efficiently. The likelyihood of scaling up PHP Workers, therefore costs, could be avoided if using Staq Cache.
• Scale PHP Workers: If the user insisted to continue using NitroPack, there’s a case here to increase PHP Workers to 15 with further monitoring required.
• Optimize Usage: Reduce reliance on preloading plugins or schedule preloading tasks during off-peak hours.

Implementing these recommendations will improve resource management and ensure optimal website performance without unnecessary overage costs.

Diagnosing Memory Issues

Firstly, you would see how much memory has been applied to the website. To do that, go to the site’s Staq Panel, followed by PHP Config. Look under Request Memory Limit. Please note that since our infrastructure pools together and uses many AWS services, server memory usage is significantly reduced compared to traditional hosting. 

Then, as per the example above, have a look at the Memory image. In your case, does memory exceed the memory assigned?

Alternatively, if your site is experiencing a critical error, it may be related to memory usage exceeding the allocated limit. The Staq Debug Tool is your first step in diagnosing WordPress memory issues.

Follow these steps:

1. Log in to the Staq Panel of the affected website.
2. Go to Advanced and click Debug:

3. Click Enable Debug in the top-right corner:

4. Go to the page showing the critical error and refresh the page to generate a log.
5. Navigate to the WordPress tab and click Refresh to display any errors:

If it was a memory issue, it will show something like this:

To increase memory, you can follow this guide on how to increase server memory/ram.