ASPnix sets fixed limits for server-side languages and the IIS web server on all shared hosting accounts. These values cannot be modified for individual sites. Classic ASP and ASP.NET share identical limits of 1 GB maximum upload file size and 90 seconds maximum execution time. PHP uses a 64 MB upload limit, 60-second script execution timeout, 1800-second maximum input timeout, and 2 FastCGI worker processes per site. The IIS configuration adds a 30-minute application pool timeout, 100 concurrent connections, package-based memory limits, and 1 GB virtual memory per worker process. If your application needs higher values or custom settings, upgrade to a VPS or dedicated server.
These restrictions exist to protect the shared environment. A single site cannot consume excessive CPU, memory, or I/O and degrade performance for others. Understanding the exact thresholds helps you design applications that stay within bounds or identify when a more powerful hosting solution is required.
#Classic ASP Limits
Classic ASP remains available for legacy applications. The platform enforces a generous 1 GB cap on uploaded files, far above the IIS default. However, the 90-second execution limit is strict. Any database calls, file operations, or business logic that exceeds this window will be terminated by the server, resulting in incomplete transactions or error pages for users.
- 1GB maximum upload file size
- 90 seconds maximum execution time
#ASP.NET Limits
All versions of ASP.NET, including .NET Framework and later releases, operate under the same constraints as Classic ASP for uploads and execution time. These limits are enforced at the ASP.NET runtime and IIS integration layers. Developers should monitor long-running page loads, web service calls, or background tasks and refactor them to complete within the allowed window.
- 1GB maximum upload file size
- 90 seconds maximum execution time
#PHP Limits
PHP runs through FastCGI on IIS. The 64 MB upload_max_filesize limit is lower than the .NET equivalent, reflecting typical PHP usage patterns. The 60-second max_execution_time prevents runaway scripts, while the 1800-second max_input_time specifically accommodates slow file uploads without triggering execution timeouts. Only two FastCGI worker processes are allocated per site, restricting concurrent PHP request handling.
- 64MB maximum file size for uploaded files
- 60 seconds maximum script execution timeout
- 1800 seconds maximum input timeout (wait for uploading files)
- 2 FastCGI worker processes per website
#IIS Web Server and Application Pool Settings
The underlying IIS configuration governs connection handling and process lifetime. Application pools recycle after 30 minutes of inactivity or according to memory thresholds set by your hosting package. Each worker process is capped at 1 GB of virtual memory. The 100-connection limit applies to simultaneous HTTP requests; exceeding it results in connection refusals or queuing.
- 30 minute application pool (worker process) timeout
- 100 concurrent connections
- Application pool memory limits are based on the purchased shared hosting package
- 1GB virtual memory allowed per site (worker process)
#Configuring Within the Allowed Limits
You may configure lower values than the server maximums in your application code or configuration files. For ASP.NET applications, the web.config httpRuntime element can explicitly set executionTimeout and maxRequestLength up to the platform limits. Setting values higher than the server enforces will have no effect.
<configuration>
<system.web>
<httpRuntime executionTimeout="90" maxRequestLength="1048576" />
</system.web>
</configuration>In PHP, calls to ini_set() for upload_max_filesize or max_execution_time cannot exceed the server-wide values. Long-running operations should be moved to queued background jobs or broken into multiple requests using AJAX or scheduled tasks.
#Common Pitfalls and Troubleshooting
Developers frequently encounter these limits when migrating applications that assume unlimited resources. Large CSV imports, heavy image processing, or unoptimized SQL queries easily exceed the 60- or 90-second execution caps. The PHP 64 MB upload limit often surfaces with media-heavy CMS installations. The two-worker FastCGI restriction can cause queuing under moderate concurrent load. Monitor application logs for timeout errors and connection limits. Optimize code, add indexing to databases, compress uploads, and consider client-side processing where possible.
ASPnix does not make per-site adjustments to these settings. Requests for increased limits on shared hosting will be declined. Evaluate your application's resource profile during development and load testing. When requirements consistently exceed the documented thresholds, a VPS or dedicated server provides the necessary flexibility to tune execution timeouts, worker process counts, memory allocation, and connection limits to match your workload.
Review your current hosting package memory entitlements and test representative workloads before going live. For guidance on optimizing ASP.NET or PHP code to remain within these boundaries, consult the related articles on performance tuning and database best practices in the knowledge base.
Comments
No comments yet