Choosing the Right PHP memory_limit, max_execution_time and upload_max_filesize for Your Website

PHP settings like memory_limit, max_execution_time and upload_max_filesize look like small configuration lines, but they directly decide whether your website quietly works… or constantly hits white screens, 500 errors and failed uploads. When we review new sites that move to our infrastructure at dchost.com, these three values are among the first things we check. They affect everything from WordPress and WooCommerce to Laravel, custom APIs, LMS platforms and even small corporate sites. The goal is not to push all limits to extreme values, but to set realistic numbers that match your code, traffic, and hosting resources.

In this guide, we will walk through what each of these PHP directives actually does in real life, common mistakes we keep seeing, and safe baseline values for different types of projects. You will see how to change them on shared hosting, cPanel/DirectAdmin, and VPS or dedicated servers, and how to debug when you still hit limits. By the end, you will have a practical checklist you can apply immediately on your own hosting or on your servers at dchost.com.

Why These PHP Settings Matter More Than You Think

From a distance, memory and time limits look like pure backend concerns. In practice, they shape user experience, SEO and even conversion rates. Here is what they really control:

• memory_limit: How much RAM a single PHP process can use. Too low and you get fatal errors; too high and a few heavy requests can exhaust server RAM.
• max_execution_time: How long PHP is allowed to run a script. Too low and long operations break; too high and you can keep stuck processes hanging around.
• upload_max_filesize (and related post_max_size): The maximum size of files (forms) users can upload. Too low and file uploads silently fail; too high and you risk abuse and wasted resources.

These directives interact with your web server (Apache, Nginx, LiteSpeed), database timeouts, and even CDN or WAF settings. They are also one of the root causes behind issues like the WordPress white screen problem. If you have struggled with that, you may want to read our detailed guide on fixing the WordPress White Screen of Death from the hosting side after finishing this article.

Understanding memory_limit: How Much PHP Memory Do You Really Need?

What memory_limit Actually Controls

memory_limit defines the maximum amount of RAM that a single PHP script (a single request) is allowed to allocate. This is not total server RAM, and it is not per user; it is per PHP process. If a script exceeds this value, PHP stops execution and logs an error similar to:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

134217728 bytes is 128M; you will often see this in logs when a plugin, theme, or custom script tries to load too much data into memory at once (for example, a huge WooCommerce product export or a poorly written report query).

Typical Defaults and When They Fail

Common defaults on many hosting environments:

• 64M or 128M on older shared hosting plans
• 256M on more modern setups
• 512M or more on tuned VPS / dedicated environments for heavy applications

Where these defaults often fail in real projects:

• WordPress with many plugins: Page builders, security suites, analytics, WooCommerce, and translation plugins quickly push beyond 128M.
• WooCommerce, Magento or other e‑commerce: Bulk imports, large product catalogs, and complex cart/checkout logic can easily hit 256M or more.
• LMS platforms (Moodle, custom LMS): Reporting, grade exports and complex queries often need more RAM during peak processes.
• Image-heavy or PDF‑heavy workflows: Any script that resizes or manipulates large images or PDFs can spike memory usage.

We cover broader performance tuning for LMS workloads in our Moodle and LMS hosting performance guide, where memory_limit is one of the key levers.

How to Estimate a Reasonable memory_limit

There is no single magic number, but you can estimate a safe value by thinking about three things:

1. The heaviest operation on your site (e.g. product import, backup, report)
2. Concurrent PHP processes (how many requests can run at the same time)
3. Total RAM available for PHP (after the OS, database, cache, web server, etc.)

Assume:

• Your heaviest request needs around 256M to complete comfortably.
• Your PHP-FPM pool can handle 20 concurrent workers.
• You are on a VPS with 4 GB RAM, and you want to reserve about half (2 GB) for PHP.

In this scenario, 20 workers × 256M = 5120M (≈5 GB) theoretical max usage, which is more than your server RAM. In real life, not all workers hit peak memory at the same time, but this calculation shows that setting memory_limit to 256M with 20 workers may be too optimistic for a 4 GB VPS unless you reduce workers, optimize code, or increase RAM.

Practical Baselines for memory_limit

Based on real-world sites we host and tune, a practical starting point is:

• Simple blogs or small business sites: 128M–256M
• Standard WordPress with several plugins: 256M
• WooCommerce or other e‑commerce: 256M–512M (sometimes higher for large stores)
• LMS, CRM, ERP, SaaS backends: 512M+ for heavy admin operations, with appropriate worker limits

These must align with available RAM. On a tiny shared hosting plan, jumping to 1024M memory_limit does not magically give you more RAM; it just makes it easier to overload the server. On a VPS or dedicated server at dchost.com, you can tune PHP-FPM pools and memory_limit together to match the actual RAM you are paying for.

For a more holistic look at server-side tuning for WordPress, including PHP-FPM and OPcache, you may also want to read our article The Server-Side Secrets That Make WordPress Fly.

How to Set memory_limit (php.ini, .htaccess and Per-Site)

You can change memory_limit via several methods, depending on hosting:

• php.ini (global or per PHP version)
• .user.ini (per directory, often on shared hosting)
• .htaccess (for Apache with mod_php or certain handlers)
• Control panel UI (cPanel, DirectAdmin, Plesk selectors)

Examples:

; php.ini or .user.ini
memory_limit = 256M

# .htaccess
php_value memory_limit 256M

// In a PHP script (temporary change)
ini_set('memory_limit', '256M');

On cPanel or DirectAdmin, you will often find a “Select PHP Version” or “PHP Options” screen where you can pick memory_limit without editing files. For more advanced scenarios with multiple applications, see our article on managing multiple PHP versions per site on cPanel and DirectAdmin; there we also touch on per-site PHP settings.

Understanding max_execution_time: Keeping Scripts Fast and Safe

What max_execution_time Controls

max_execution_time sets the maximum CPU time in seconds that a PHP script is allowed to run. When the limit is reached, PHP terminates the script and may output a fatal error or just close the connection.

Common default values:

• 30 seconds on many shared hosting setups
• 60–120 seconds on more generous configurations
• Higher values for CLI scripts and background jobs (e.g. 300–600 seconds)

Note that for command-line PHP (php-cli), max_execution_time is often ignored or set to 0 (unlimited). Long-running tasks like queue workers and cron jobs normally use CLI and separate timeout strategies.

Where Low max_execution_time Hurts

We most commonly see timeouts in:

• Large imports/exports (CSV, XML, product lists, user lists)
• Backup or migration plugins that try to run everything in one go
• Heavy admin pages (large reports, analytics, or complex filters)
• API calls to slow third-party services where your script is waiting for an external response

If users report that “it always stops around 30 seconds” when doing a certain action, max_execution_time is a prime suspect.

Safe Ranges for max_execution_time

We like to think in tiers:

• Regular web requests: 30–60 seconds is usually enough if the code is efficient. If a page needs more than 60 seconds, it probably should be broken into smaller chunks or moved to a background job.
• Admin-only operations: 60–120 seconds can be acceptable for imports, exports and heavy actions initiated by authenticated admins.
• Background or CLI tasks: Use CLI PHP with its own supervision (cron, systemd, queue workers). Set max_execution_time to 0 for CLI and control runtime via process managers instead.

Remember: raising max_execution_time does not make slow code fast. It simply allows slow operations to finish instead of being killed. You should still profile and optimize slow queries, caches and external calls.

Timeouts Exist Across the Stack

One common troubleshooting trap: even if you increase PHP’s max_execution_time, you might still hit timeouts elsewhere:

• Web server: Apache, Nginx, or LiteSpeed have their own request and proxy timeouts.
• Load balancer / reverse proxy: Upstream timeouts may be shorter than PHP’s.
• Database: MySQL/MariaDB and PostgreSQL have query and connection timeouts.
• CDN or WAF: Some edge providers time out connections after 100 seconds or less.

That is why serious performance work always involves checking logs across components. If you want to get comfortable reading web server logs for 4xx and 5xx issues, have a look at our guide on diagnosing 4xx–5xx errors on Apache and Nginx.

How to Set max_execution_time

Common ways to set it:

; php.ini or .user.ini
max_execution_time = 60

# .htaccess
php_value max_execution_time 60

// In a PHP script (for that script only)
ini_set('max_execution_time', '60');

Before you increase it too far, ask yourself: can this operation be restructured? For example, a WooCommerce product import can often be split into smaller batches via the plugin configuration, instead of trying to process 100,000 products in one monstrous request.

upload_max_filesize and post_max_size: Getting File Uploads Right

How upload_max_filesize and post_max_size Work Together

PHP uses two directives to control uploads and POST data:

• upload_max_filesize: The maximum size of a single uploaded file.
• post_max_size: The maximum size of the entire POST request body (including all files and form fields).

Some key rules:

• post_max_size must be equal to or larger than upload_max_filesize.
• If multiple files are uploaded in one form, their total size must be within post_max_size.
• Other layers (web server, reverse proxy, WAF, CDN) may have their own body size limits.

For example, if you set:

upload_max_filesize = 32M
post_max_size = 32M

then one 32 MB file or several smaller files whose total is up to 32 MB can be uploaded in one request. If you want up to 32 MB per file and multiple files per upload, you might use:

upload_max_filesize = 32M
post_max_size = 64M

Typical Values for Different Sites

Reasonable starting points:

• Standard content sites: 8M–16M (for images and small PDFs)
• Corporate / portfolio / blogs: 16M–32M (enough for larger images, short videos, PDFs)
• E‑commerce with product images: 32M–64M (raw images, optimized later)
• LMS and file sharing features: 64M–256M or more, depending on your policy

Always tie this to a clear policy: what is the maximum file size you are comfortable with, given storage, bandwidth and security constraints? Setting everything to 1 GB just “in case” usually creates more problems than it solves, especially on smaller VPSs or shared hosting plans.

Do Not Forget Web Server Limits

Even if PHP allows 64M uploads, the web server might block them first. Examples:

• Nginx: client_max_body_size
• Apache: LimitRequestBody or module-specific limits
• Reverse proxies / CDNs: their own maximum upload S

A consistent configuration is important. For instance, on an Nginx + PHP-FPM stack for 64M uploads, you might have:

# nginx.conf or vhost
client_max_body_size 64M;

; php.ini
upload_max_filesize = 64M
post_max_size = 64M

How to Set upload_max_filesize and post_max_size

Again, you can use php.ini, .user.ini or .htaccess:

; php.ini or .user.ini
upload_max_filesize = 32M
post_max_size = 64M

# .htaccess
php_value upload_max_filesize 32M
php_value post_max_size 64M

On many control panels, these values are available under the same PHP settings interface where you changed memory_limit and max_execution_time.

Changing PHP Settings on Shared Hosting, VPS and Dedicated Servers

On Shared or cPanel/DirectAdmin Hosting

On shared hosting (including shared plans at dchost.com), your access is usually limited to per-account settings, but that is still enough for most websites. Typical approaches:

• Use the panel’s PHP Selector / MultiPHP Manager / PHP Options to change values.
• Create or edit .user.ini or .htaccess in your document root if supported.

Example workflow on cPanel-like environments:

1. Log in to the control panel.
2. Open the PHP settings tool (e.g. “Select PHP Version” then “Options”).
3. Adjust memory_limit, max_execution_time, upload_max_filesize and post_max_size.
4. Save and test by uploading a larger file or repeating the heavy operation.

If you are frequently hitting resource ceilings on shared hosting even after tuning PHP settings, it is worth reading our article on how to avoid the “Resource Limit Reached” error on shared hosting. It explains CPU, memory and I/O limits at the account level, which exist above PHP’s own limits.

On VPS and Dedicated Servers

On a VPS or dedicated server (for example, one you manage at dchost.com), you have full control over:

• Global PHP configuration (/etc/php/<version>/fpm/php.ini, cli/php.ini, etc.)
• Per-pool PHP-FPM configs to tune worker counts and memory usage
• Web server settings (Nginx/Apache body size and timeout directives)

This opens the door to more serious tuning. For example, on PHP-FPM you might:

; /etc/php/8.2/fpm/php.ini
memory_limit = 512M
max_execution_time = 60
upload_max_filesize = 64M
post_max_size = 64M

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.max_requests = 500

Here you must think about the combined effect of memory_limit and max_children. 20 children × 512M theoretical max is about 10 GB potential PHP usage, so this configuration only makes sense on a machine with enough RAM and with the understanding that not every process will reach the limit at the same time.

If you regularly handle larger loads or mission-critical applications, we strongly recommend pairing PHP tuning with broader performance and capacity planning. Our article on how much CPU, RAM and bandwidth a new website needs is a good starting point before you choose your VPS or dedicated specs at dchost.com.

Recommended Baselines and a Practical Tuning Checklist

Baseline Settings for Common Use Cases

These are not hard rules, but they work well as starting points on reasonably sized hosting plans (2–4 vCPU, 4–8 GB RAM) when balanced with correct worker counts:

Always validate against real usage: check logs, run imports or backups on staging, and watch resource graphs.

A Step-by-Step Tuning Checklist

1. Identify your heaviest operations: imports, exports, backups, large page loads, report generation.
2. Check current errors in PHP error logs and web server logs for “Allowed memory size exhausted” or timeouts.
3. Increase memory_limit in small steps (128M → 256M → 384M, etc.), testing after each change.
4. Adjust max_execution_time for operations that genuinely need more time, while keeping regular page loads within 30–60 seconds.
5. Set upload_max_filesize and post_max_size based on a clear policy for maximum upload size.
6. Align web server settings (client_max_body_size, timeouts) with PHP limits.
7. Monitor impact on RAM, CPU and disk I/O. If you are constantly near the ceiling, tune PHP-FPM workers or consider a larger plan at dchost.com.

If you are in the process of upgrading to PHP 8.x, make sure you also review our PHP 8.x upgrade checklist, where we combine version upgrades, OPcache tuning and PHP-FPM pool settings with these basic directives.

Troubleshooting When You Still Hit Limits

If you have increased limits and still face issues:

• Look for specific error messages in PHP and web server logs, not just on screen.
• Check cPanel or panel resource usage charts to see if CPU/IO/EP limits are being hit.
• Profile slow pages or operations: sometimes one plugin or query is the entire problem.
• Use staging to reproduce and test with different settings before changing production.

Our article on understanding cPanel resource limits is a useful companion here, because it explains the outer boundaries that surround your PHP settings on shared hosting.

When PHP Settings Are Not Enough: Time to Rethink Hosting

Sometimes the problem is not your config values, but the physical limits of your hosting environment. Signs that it is time to upgrade or re-architect include:

• You have already set reasonable PHP limits and optimized code, but still hit memory or CPU bottlenecks.
• Simple traffic spikes regularly push your site into 500 errors or timeouts.
• You need consistently higher upload limits and background processing than shared hosting comfortably supports.
• Your site is growing into a full e‑commerce or SaaS platform with predictable high loads.

In those cases, moving from entry-level shared hosting to a VPS or dedicated server is often the cleanest next step. At dchost.com, we provide shared hosting, VPS, dedicated and colocation options, so you can match PHP limits with actual hardware resources instead of fighting within tight ceilings.

For a structured way to detect when an upgrade is truly necessary, not just “nice to have”, you can check our article on server-side signals that it is time to upgrade your hosting plan. Combining those signals with the PHP tuning steps in this article will give you a clear roadmap.

Wrapping Up: Make PHP Limits Work For You, Not Against You

PHP settings like memory_limit, max_execution_time and upload_max_filesize are not just random numbers you copy from a tutorial. They are guardrails that protect your server resources while still allowing your applications to do real work. When they are too low, you see white screens, broken uploads and failed imports. When they are too high on undersized infrastructure, a few heavy requests can consume all RAM or CPU and slow down everything else.

The best approach is systematic: understand what each directive does, start from sane baselines for your type of site, and then adjust based on actual usage, logs and monitoring. On shared hosting, use panel tools and per-directory configuration to stay within account limits. On VPS or dedicated servers, combine PHP settings with tuned PHP-FPM pools, web server limits and properly sized hardware.

If you are hosting with dchost.com or considering moving your sites to us, our team can help you align these PHP values with the right hosting plan, whether that is shared hosting for a small corporate site, an NVMe VPS for WordPress and WooCommerce, or a dedicated server or colocation setup for custom PHP applications. Configure your limits thoughtfully once, and you will spend far less time chasing random errors and far more time building the features your visitors actually see.