PHP Configuration
PHP Configuration Interview with follow-up questions
1. What is the purpose of the php.ini file?
php.ini is the master configuration file that controls PHP's behavior at runtime. PHP loads it when the SAPI (web server module, PHP-FPM, or CLI) starts.
Key configuration areas:
Error handling
error_reporting = E_ALL
display_errors = Off ; Off in production, On in development
log_errors = On
error_log = /var/log/php/error.log
Performance and resource limits
max_execution_time = 30 ; seconds (0 = unlimited in CLI)
memory_limit = 256M
max_input_time = 60
File uploads
file_uploads = On
upload_max_filesize = 10M
post_max_size = 12M ; must be larger than upload_max_filesize
Session
session.gc_maxlifetime = 1440
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
OPcache (critical for production performance)
opcache.enable = 1
opcache.memory_consumption = 128
opcache.validate_timestamps = 0 ; disable in production for max performance
Finding and modifying php.ini:
php --ini # shows which php.ini is loaded
php -i | grep php.ini # same
You can also override specific directives per-request using ini_set() in code, or per-directory using .user.ini in web contexts.
Interview tip: Know the difference between the CLI php.ini and the web SAPI php.ini — they are often different files with different settings (e.g., max_execution_time = 0 in CLI).
Follow-up 1
Can you mention some of the directives that can be set in this file?
Yes, there are numerous directives that can be set in the php.ini file. Some common directives include:
display_errors: Controls whether PHP displays error messages on the screen.error_reporting: Sets the level of error reporting.date.timezone: Sets the default timezone used by PHP.max_execution_time: Sets the maximum execution time for PHP scripts.upload_max_filesize: Sets the maximum file size for file uploads.extension_dir: Specifies the directory where PHP extensions are located.
These are just a few examples, and there are many more directives available.
Follow-up 2
How can you check the current configuration settings in PHP?
To check the current configuration settings in PHP, you can use the phpinfo() function. This function outputs a comprehensive report of PHP's configuration, including all the directives and their current values. Simply call phpinfo() in a PHP script and run it in a web browser to see the configuration details.
Follow-up 3
What is the order of precedence when there are multiple php.ini files?
When there are multiple php.ini files, PHP follows a specific order of precedence to determine which configuration settings to use. The order is as follows:
- The php.ini file specified in the
PHPIniDirdirective in the web server configuration. - The php.ini file in the PHP installation directory.
- The php.ini file in the Windows directory (for Windows installations).
- The php.ini file in the system's default location (e.g.,
/etc/php.inion Unix-like systems).
If multiple php.ini files are found, PHP will merge their settings, with the last file taking precedence in case of conflicting directives.
Follow-up 4
How can you change the configuration settings at runtime?
In PHP, you can change certain configuration settings at runtime using the ini_set() function. This function allows you to modify the value of a configuration directive temporarily for the duration of the script execution. For example, to change the display_errors directive, you can use the following code:
ini_set('display_errors', 'On');
Note that not all configuration settings can be changed at runtime, and some settings may require special permissions or server configurations to be modified.
2. What is the max_execution_time directive in PHP?
max_execution_time sets the maximum number of seconds a PHP script is allowed to run before PHP terminates it with a fatal error:
Fatal error: Maximum execution time of 30 seconds exceeded
Default value: 30 seconds (for web requests). In PHP CLI mode, the default is 0 (unlimited).
Configuration:
; php.ini
max_execution_time = 30
// Override at runtime
ini_set('max_execution_time', 60);
set_time_limit(60); // equivalent; resets the counter from the current point
set_time_limit(0); // unlimited — use with caution
Important nuances:
- The timer counts CPU time used by PHP, not wall-clock time. On Linux, time spent waiting for I/O (database queries, file reads, network calls) does not count toward the limit — only time the PHP process is actively executing. On Windows, wall time is used.
max_execution_timedoes not apply tosleep()calls — those pause PHP, not consume CPU.- For long-running CLI tasks (queue workers, import scripts), set it to
0or useset_time_limit(0).
Interview context: A common production problem is a slow database query causing a timeout. The fix is usually to optimize the query or move the work to a background job, not to simply increase max_execution_time.
Follow-up 1
What happens when a script exceeds this time limit?
When a script exceeds the max_execution_time limit, it will be terminated by PHP and an error message will be displayed. The default error message is 'Maximum execution time of X seconds exceeded', where X is the value of the max_execution_time directive.
Follow-up 2
How can you change this setting at runtime?
The max_execution_time setting can be changed at runtime using the ini_set() function in PHP. For example, to set the max_execution_time to 60 seconds, you can use the following code:
ini_set('max_execution_time', 60);
Follow-up 3
What are some scenarios where you might need to increase this limit?
There are several scenarios where you might need to increase the max_execution_time limit:
- When running long-running scripts or tasks that require more time to complete.
- When working with large datasets or performing complex calculations that take longer to process.
- When making API requests or performing network operations that may take longer to complete.
- When debugging or profiling code that requires more time to analyze.
It is important to note that increasing the max_execution_time should be done cautiously and only when necessary, as it can have implications on server performance and resource usage.
Follow-up 4
What are the implications of setting this value too high?
Setting the max_execution_time value too high can have several implications:
- Increased server resource usage: Scripts that run for a long time consume more server resources, such as CPU and memory, which can affect the overall performance and stability of the server.
- Increased risk of script timeouts: If the max_execution_time is set too high, it may result in scripts running indefinitely, leading to potential timeouts and resource exhaustion.
- Security risks: Long-running scripts can be exploited by attackers to perform denial-of-service (DoS) attacks or consume excessive server resources.
Therefore, it is important to carefully consider the value of max_execution_time and set it to an appropriate value based on the specific requirements of your application.
3. What is the memory_limit directive in PHP?
memory_limit sets the maximum amount of memory (RAM) that a single PHP script is allowed to allocate. If a script exceeds this limit, PHP throws a fatal error:
Fatal error: Allowed memory size of 134217728 bytes exhausted
Default value: 128M (as of PHP 8.x).
Configuration:
; php.ini
memory_limit = 256M
// Override at runtime
ini_set('memory_limit', '512M');
ini_set('memory_limit', '-1'); // unlimited — use only in controlled CLI scripts
Check current memory usage in code:
echo memory_get_usage(true); // current memory used (bytes)
echo memory_get_peak_usage(true); // peak memory used during the request
Common causes of memory exhaustion:
- Loading a large CSV or Excel file entirely into memory
- Fetching thousands of rows from a database into an array
- Recursive algorithms with deep call stacks
- Memory leaks in long-running CLI processes
Solutions:
- Use generators or streaming/chunked processing instead of loading entire datasets into arrays
- Use
PDO::FETCH_UNBUFFERED_QUERYorMYSQLI_USE_RESULTto stream database results row-by-row - Profile with tools like Blackfire or Xdebug's memory profiling to find leaks
Interview note: Increasing memory_limit as a fix is a band-aid. The real fix is usually more memory-efficient data processing.
Follow-up 1
What happens when a script exceeds this memory limit?
When a script exceeds the memory_limit, it will trigger a fatal error and the script execution will be terminated. This error message will be displayed: 'Fatal error: Allowed memory size of xxxxx bytes exhausted (tried to allocate xxxxx bytes)'.
Follow-up 2
How can you change this setting at runtime?
The memory_limit setting can be changed at runtime using the ini_set() function in PHP. Here's an example:
ini_set('memory_limit', '256M');
Follow-up 3
What are some scenarios where you might need to increase this limit?
There are several scenarios where you might need to increase the memory_limit:
- When working with large datasets or processing large files.
- When using memory-intensive libraries or frameworks.
- When running complex algorithms or computations that require a significant amount of memory.
- When dealing with recursive functions or deep object hierarchies that consume a lot of memory.
Follow-up 4
What are the implications of setting this value too high?
Setting the memory_limit value too high can have several implications:
- It can lead to excessive memory usage and potentially cause the server to run out of memory, resulting in performance issues or crashes.
- It can make your application more vulnerable to memory leaks or inefficient memory usage, as there is no limit to how much memory a script can consume.
- It can make your application less scalable, as it may require more resources to handle concurrent requests.
- It can mask underlying memory-related issues in your code, making it harder to identify and fix them.
4. What is the error_reporting directive in PHP?
error_reporting is a PHP configuration directive (and function) that specifies which types of errors should be generated. It accepts a bitmask of error-level constants.
Configuration in php.ini:
; Development
error_reporting = E_ALL
; Production (hide deprecation notices, show real problems)
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
Setting programmatically:
error_reporting(E_ALL); // all errors
error_reporting(E_ALL & ~E_NOTICE); // all except notices
error_reporting(0); // suppress all (not recommended)
Error levels:
| Constant | Meaning |
|---|---|
E_ERROR |
Fatal errors — script halts |
E_WARNING |
Non-fatal warnings |
E_NOTICE |
Informational notices (e.g., undefined variable) |
E_DEPRECATED |
Use of deprecated features |
E_USER_ERROR |
User-generated fatal error via trigger_error() |
E_ALL |
All of the above |
PHP 8.x changes: Many operations that previously raised E_NOTICE or E_WARNING now throw typed exceptions (TypeError, ValueError). Accessing undefined array keys still raises E_WARNING, but accessing undefined variables now throws E_WARNING (it was E_NOTICE in PHP 7).
Interview tip: In production, error_reporting = E_ALL combined with log_errors = On and display_errors = Off is the correct setup — log everything, show nothing to users.
Follow-up 1
What are the different levels of error reporting in PHP?
The different levels of error reporting in PHP are:
- E_ALL: All errors and warnings, including E_STRICT
- E_ERROR: Fatal run-time errors
- E_WARNING: Run-time warnings (non-fatal errors)
- E_PARSE: Compile-time parse errors
- E_NOTICE: Run-time notices
- E_DEPRECATED: Notices for deprecated features
- E_STRICT: Enable PHP's strict standards
These levels can be combined using the bitwise OR operator (|) to specify multiple levels of error reporting.
Follow-up 2
How can you change this setting at runtime?
The error_reporting setting can be changed at runtime using the error_reporting() function. This function accepts a bitmask or one of the predefined error reporting constants (e.g., E_ALL, E_ERROR, etc.) as its parameter. For example, to enable all error reporting levels, you can use:
error_reporting(E_ALL);
To disable error reporting, you can use:
error_reporting(0);
Follow-up 3
What is the difference between E_ALL and E_STRICT?
The difference between E_ALL and E_STRICT is that E_ALL includes all error reporting levels, including E_STRICT. E_STRICT is a level of error reporting that enables PHP's strict standards, which are a set of coding guidelines and recommendations to ensure better code quality and compatibility. E_STRICT is not included in E_ALL by default, but it can be combined with other error reporting levels using the bitwise OR operator (|).
Follow-up 4
What are the implications of turning off error reporting?
Turning off error reporting can have several implications:
- Debugging becomes more difficult as errors and warnings are not displayed or logged.
- Potential security vulnerabilities may go unnoticed as error messages can reveal sensitive information about the server or application.
- Code quality may suffer as developers may not be aware of potential issues or deprecated features.
It is generally recommended to keep error reporting enabled during development and testing, and only disable it in production environments for security and performance reasons.
5. What is the display_errors directive in PHP?
display_errors is a PHP configuration directive that controls whether error messages are output to the browser/stdout.
; Development — see errors immediately
display_errors = On
; Production — never show errors to users
display_errors = Off
Why Off in production is critical:
- Error messages expose internal file paths, database structure, class names, and query logic — all valuable information for attackers.
- Stack traces include environment details that aid exploitation.
- A blank or generic error page is far safer and provides a better user experience.
The correct production configuration:
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log
error_reporting = E_ALL
Log everything, display nothing. Use an error monitoring service (Sentry, Bugsnag, Rollbar) to get alerts and aggregated stack traces from production without exposing them to users.
Override at runtime (for debugging on production — use with caution):
ini_set('display_errors', '1');
error_reporting(E_ALL);
display_startup_errors is a related directive that controls whether errors that occur during PHP's startup sequence are displayed. Set it to Off in production as well.
Interview tip: Interviewers often ask about the proper php.ini settings for development vs production. Know the full trio: display_errors, log_errors, and error_reporting.
Follow-up 1
What are the implications of turning on display_errors in a production environment?
Turning on display_errors in a production environment can be a security risk as it may expose sensitive information about your application to potential attackers. Error messages can contain valuable information such as file paths, database credentials, and other details that can be exploited.
It is recommended to keep display_errors turned off in a production environment and instead log errors to a secure error log file. This way, you can still capture and debug errors without exposing sensitive information to the public.
Follow-up 2
What is the difference between display_errors and log_errors?
The display_errors and log_errors directives in PHP control how errors are handled.
- display_errors determines whether errors should be displayed on the screen or not.
- log_errors determines whether errors should be logged to the error log file or not.
When display_errors is set to On, errors will be displayed on the screen. When set to Off, errors will not be displayed on the screen, but will still be logged to the error log file if log_errors is set to On.
Follow-up 3
How can you change this setting at runtime?
The display_errors directive can be changed at runtime using the ini_set() function in PHP. Here's an example:
ini_set('display_errors', 'On');
This will enable the display of errors on the screen. Similarly, you can set it to 'Off' to disable the display of errors.
Follow-up 4
How can you log errors to a custom file in PHP?
To log errors to a custom file in PHP, you can use the error_log() function. Here's an example:
error_log('An error occurred', 3, '/path/to/error.log');
This will log the error message 'An error occurred' to the file located at '/path/to/error.log'. The '3' parameter specifies that the error should be appended to the file.
You can also configure the error_log directive in the php.ini file to specify a default error log file for all errors.
Live mock interview
Mock interview: PHP Configuration
- Read your scene and goals
- Talk it out; goals tick off live
- Get a score and stronger lines
Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.