I need to change the OpenSSL config used by PHPs openssl* methods. phpinfo() reports the default openssl config as present in /etc/ssl/openssl.cnf. However, it does not seem to use it.
I changed the openssl.cnf to have some invalid values in it. Running openssl from the shell righfully fails and complains about an invalid config. The openssl* methods in my PHP script still continue to work?! They should fail with the same error message.
So, what OpenSSL config is PHP actually using?
PHP is running as Apache2 module in an Alpine Linux Docker Container (Package php81-apache2)
There seems to be some caching involved (have to investigate later). After letting the system sit for a few hours the PHP methods used the changed configuration.
My code detects the environment from multiple factors and sets all environment variables and constants based on the autodetected environment.
I have the following line in my code:
ini_set('zend.assertions',environment_among(PRODUCTION) ? -1 : 1);
Don't worry about environment_among(PRODUCTION). The issue is that this line throws this warning: Warning: zend.assertions may be completely enabled or disabled only in php.ini
Since this setting depends on the environment as detected by the code, I can't put this setting in the server's php.ini file. How can I configure this locally? A solution that uses Composer is acceptable.
According to the documentation and the ticket that updated the documentation, your php.ini should be set to 0 in order to dynamically change this at runtime. There are third-party assert libraries but the performance-optimized assert can only be handled by the runtime since it is a compilation step.
I'm working on an apache server (not in localhost) with symfony 4
I have my WebProfilerBundle bundle enable only in dev environment
My DoctrineBundle is enable everywhere
When I update (php bin/console doctrine:schema:update) I always get a
[CAUTION] This operation should not be executed in a production environment!
Even if my APP_ENV=dev and even if I am can see my WebProfiler.
Someone know why ?
Unless you are just 'dumping' the SQL that would be run, or you are explicitly adding the '--force' parameter, it will always show the warning.
I'm not sure why, but xdebug does not highlight var_dump(). But config seems to be fine. Have no idea why... Any suggestions?
This is my phpinfo(); http://pastebin.com/A45dqnWN
plus even xdebug_var_dump() doesn't highlight anything. It works, but look like normal var_dump().
I found that option "xdebug.default_enable Off Off" in you php_info(). I also have noticed that in last versions of EasyPHP this option is turned off. So turn it on by setting this line in php.ini:
xdebug.default_enable=1
Next is just common operation which disables var_dump and other errors in HTML output completely (not your case, but maybe helpful for others):
html_errors = On
For Xdebug 3 you need to enable develop mode in your php.ini:
xdebug.mode= develop
You can also use multiple modes at once as explained here.
The following values are accepted (for xdebug.mode):
off
Nothing is enabled. Xdebug does no work besides checking whether functionality is enabled. Use this setting if you want close to 0 overhead.
develop
Enables Development Helpers including the overloaded var_dump().
coverage
Enables Code Coverage Analysis to generate code coverage reports, mainly in combination with PHPUnit.
debug
Enables Step Debugging. This can be used to step through your code while it is running, and analyse values of variables.
gcstats
Enables Garbage Collection Statistics to collect statistics about PHP's Garbage Collection Mechanism.
profile
Enables Profiling, with which you can analyse performance bottlenecks with tools like KCacheGrind.
trace
Enables the Function Trace feature, which allows you record every function call, including arguments, variable assignment, and return value that is made during a request to a file.
You can enable multiple modes at the same time by comma separating their identifiers as value to xdebug.mode: xdebug.mode=develop,trace.
As mentioned by #Shadoweb for Xdebug v3 you want debug to allow stopping at breakpoints, and develop to format the var_dump
The following you'll likely want in php.ini therefore:
xdebug.mode=develop,debug
As an aside, I also needed xdebug.start_with_request=yes to replace the renamed xdebug.xdebug.remote_enable=1 setting to get step debugging working in my IDE.
For php 7.0.2 and xdebug 2.4.0
xdebug.default_enable=1
+
html_errors = On
Still does not colorize xdebug_var_dump() output.
but this patch fixes my issue. It applies to the xdebug.c and xdebug_var_dump() only. I think they made a mistake that xdebug_var_dump works only if it need to be overload function.
## -2191,11 +2191,6 ##
int i, len;
char *val;
- if (!XG(overload_var_dump)) {
- XG(orig_var_dump_func)(INTERNAL_FUNCTION_PARAM_PASSTHRU);
- return;
- }
-
argc = ZEND_NUM_ARGS();
#if PHP_VERSION_ID >= 70000
Turn off xdebug.mode=debug in php.ini like
;xdebug.mode=debug
and restart Apache.
The title pretty much says it all...is it a bad idea ? I'd like to have the enhanced debug messages that XDebug provides on the server.
[edit]
Just to make things clear. I'm aware there are security risks involved. Perhaps I should complement my question and give more precise reasons why I would want to do this.
Our production server hosts a testing platform also. Sometimes we use it to test things on a environment as close to production as possible. The main thing I'm looking for is using XDebug's enhanced var_dump().
This is not an app server for high traffic apps and performance is not that big of an issue. I was just curious if performance would be noticeably impacted by XDebug.
Besides, I guess I could enable it only for the VirtualHost that defines the testing sites.
Besides the obvious fact that debug messages cannot be displayed in a application that is already in production, and also the fact that I don't know why would you like that, there a couple of things really bad about it.
The first one is that when you add debugging behavior to your server, the debug engine "attaches" to the PHP process and receive messages of the engine to stop at breakpoints, and this is BAD, because introduces a high performance blow to have another process stopping or "retaining" the PHP parser.
Another big issue is that when a debugger is installed, at least most of them, they tend to have the nasty habit of opening ports in your server, because they are not intended for production environments, and as you may know, any software that opens ports in your server is opening a door for any hacker around.
If you need to have debugging in your code, then in your application, implement a debugging system, if is not available, since most frameworks have this built in. Set a configuration value, say DEBUG_ENABLED and when throwing exceptions, if is not enabled, redirect to a petty page, else to a ugly page with debugging information, but take good care of what debugging information you display in your server.
I hope this clarifies everything.
EDIT As apparently my response is not documented enough, you should check these sources
PHPs XDebug tracing overhead in production
Careful: XDebug can skew your performance numbers
Finally, there is one thing I didn't said as I thought it was sort of implicit: It's common sense not do it! You don't put debugging instruments on your production server for the same reason that you keep them on a different environment, because you need to keep unnecessary stuff away from it. Any process running on a server, no matter how light it is, will impact your performance.
Slow down by factor 4
I made some tests just enabling the module, without actually debugging, makes slows down a request on my development machine from 1 second to around 4 seconds
Removing xdebug completely (even when it was not enabled) gave us 50% in page load boost (down from 60ms to 30ms). We had xdebug sitting "dormant" (waiting for trigger). We thought that since it's dormant it won't cause any harm, but boy were we wrong.
We commented out the zend_extension line in the php config at around 21:43. Average load dropped from 0.4 to 0.2 per core as well:
Why on earth do you want something like that? Debug before you deploy to production. It will make the app slower.
You should never keep that on production.
Your application shoud never need to print out "those nice debug messages", as they are not nice at all to your users. They are a sign of poor testing and they will kill user's trust, especially in a enterprise/ecommerce environment.
Second, the more detailed technical information you reveal, the more you are likely to get hacked (especially if you are already revealing that there ARE in fact problems with your code!). Production servers should log errors to files, and never display them.
Speed of execution is your least concern, anyway it will be impacted by it, as will memory.
Xdebug is for adding full stack traces to error logs, that is the display_errors ini value, which of course should be Off (even in development I dont want this). It does not allow remote attachment to a debugger unless you enable the remote_attach ini setting. While it is slower, if you have a PHP mystery error like Max memory allocated or Segmentation fault, this is the only way you will see where it actually hapenned.
You could always clone your live server with the exactly same configuration, except that it wouldn't be public.
Then you can install XDebug on it and debug things with the almost exactly the same conditions (well, load will be different between real life and the clone, but the rest will be the same).
In that case you debug things on a live environment, but real live is not affected.
Note: Obviously it does not apply to anyone. Not everyone can easily clone a server. If you use cloud services like AWS etc. it would be very easy. If you use server configuration tools like Ansible, Chef, Puppet for building your server this is a piece of cake as well.
I know this is an old post, but since the issue with Xdebug is still there 10 years on, I'd like to point to the relevant bug report (closed as WONTFIX NOTABUG): https://bugs.xdebug.org/view.php?id=1668
Tl;dr:
Just installing xdebug will (on linux #least) slow all php on the site to a crawl, with hits anywhere from 2x to 20x, even if all flags are set to OFF. DO NOT INSTALL xdebug IN PRODUCTION - EVER. Better yet, investigate less intrusive debug options.
You should never display debug error messages on a production server. It's ugly for your users and also a security risk. I'm sure it will make it a little slower too.
I tested the performance impact using this php benchmark tool. Disclaimer I built the tool.
The answer is the xdebug module significantly slows down code execution: from 2x to 7x times depending on the test. Here are my results:
# env information
php version : 7.4.5
platform : WINNT x64
# disable xdebug extension in php.ini
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_off
# enable xdebug extension
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_on
# compare
$ php src/compare.php --file1 benchmark_xdebug_off_20201127-0946.txt --file2 benchmark_xdebug_on_20201127-0939.txt
------------------------------------------------
test_math OFF ON
mean : 3762 531 -85.9%
median : 4226 568 -86.6%
mode : 4655 596 -87.2%
minmum : 918 188 -79.5%
maximum : 4722 612 -87.0%
quartile 1 : 3081 490 -84.1%
quartile 3 : 4580 595 -87.0%
IQ range : 1498 105 -93.0%
std deviation : 984 87 -91.1%
normality : 11.0% 11.0%
------------------------------------------------
test_strings
mean : 1419 677 -52.3%
median : 1521 688 -54.7%
mode : 1580 974 -38.4%
minmum : 537 90 -83.2%
maximum : 1629 1071 -34.3%
quartile 1 : 1319 452 -65.7%
quartile 3 : 1582 892 -43.6%
IQ range : 262 440 67.8%
std deviation : 226 248 9.8%
normality : 6.6% 6.6%
------------------------------------------------
test_loops
mean : 8131 1208 -85.1%
median : 8617 1240 -85.6%
mode : 9109 1407 -84.6%
minmum : 3167 589 -81.4%
maximum : 9666 1435 -85.2%
quartile 1 : 7390 1116 -84.9%
quartile 3 : 9253 1334 -85.6%
IQ range : 1863 217 -88.3%
std deviation : 1425 164 -88.4%
normality : 5.6% 5.6%
------------------------------------------------
test_if_else
mean : 279630 31263 -88.8%
median : 293553 31907 -89.1%
mode : 303706 37696 -87.6%
minmum : 104279 12560 -88.0%
maximum : 322143 37696 -88.3%
quartile 1 : 261977 28386 -89.2%
quartile 3 : 307904 34773 -88.7%
IQ range : 45927 6387 -86.1%
std deviation : 39034 4405 -88.7%
normality : 4.7% 4.7%
------------------------------------------------
test_arrays
mean : 5705 3275 -42.6%
median : 5847 3458 -40.9%
mode : 6040 3585 -40.6%
minmum : 3366 1609 -52.2%
maximum : 6132 3645 -40.6%
quartile 1 : 5603 3098 -44.7%
quartile 3 : 5965 3564 -40.3%
IQ range : 361 465 28.8%
std deviation : 404 394 -2.5%
normality : 2.4% 2.4%
------------------------------------------------
You can use XDebug in production if you "do it right". You can enable the extension in a "dormant" mode that is only brought to live through requests that go through a specific HOSTS name. Se details here:
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug