We are having problems with our containers in our ECS service. The purpose of this service is to receive data and save it to s3. Service is running fine until it is being used in production and healtcheck start failing.
For our healthcheck we use this line to determine php-fpm state:
cgi-fcgi -bind -connect localhost:9001
From tailing php fpm log in /var/log I can see this line over and over again:
[pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers)
Now I found many articles explaining how to set php fpm settings for my application, primarily this one: https://thisinterestsme.com/php-fpm-settings/
Based on the article I can see that we have 2 cores and each php-fpm process averages 40MB. Our total RAM is around 16GB. Based on these settings I can calculate php-fpm server values:
pm.max_children = 16GB / 40MB = 400
pm.start_servers = 2 cores x 4 = 8
pm.max_spare_servers = 2 cores x 4 = 8
pm.min_spare_servers = 2 cores x 2 = 4
I tried way bigger settings as well like start_servers = 32, but I am still receiving same warnings, which makes me think something is not configured properly.
I am trying to profile Laravel 5.5 app on Windows 8.1 machine with xdebug 2.5.5 php version 7.0.0. php is running as cgi
Debugging works excellent i can debug but the profiler files are filled with this Laravel error (this is only with Laravel app, in simple php file profiling works fine):
version: 1 creator: xdebug 2.5.5 (PHP 7.0.15-dev)
cmd: D:\www\laravel55\vendor\laravel\framework\src\Illuminate\Foundation\Bootstrap\HandleExceptions.php
part: 1
positions: line
events: Time
fl=(1)
fn=(2770) php::error_get_last
122 0
fl=(1)
fn=(74)
122 0
fl=(88)
fn=(2771) Illuminate\Foundation\Bootstrap\HandleExceptions->handleShutdown
120 73
cfl=(1)
cfn=(2770)
calls=1 0 0
122 0
cfl=(1)
cfn=(74)
calls=1 0 0
122 0
I have tried with xdebug 2.5.5 php version 7.1.9. same thing.
This are xdebug settings:
[Xdebug]
zend_extension="D:\AppServ\xdebug\php_xdebug-2.5.5-7.1-vc14-nts.dll"
xdebug.remote_enable=1
;xdebug.remote_port="<the port for Xdebug to listen to>" (the default port is 9000)
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.profiler_enable_trigger_value=1
xdebug.remote_autostart=1
xdebug.profiler_output_dir="D:\AppServ\xdebug\tmp"
xdebug.idekey="PHPSTORM"
The grid file is probably empty because it is overwritten several times in the same request.
You can add the timestamp + script location into the filename to prevent this:
xdebug.profiler_output_name = "cachegrind.out.%t-%s"
PHP runs so slowly on my Windows desktop that phpMyAdmin takes minutes to open a database. Here’s a comparison of the time to run a simple PHP test program:
Windows 8.1 machine running XAMPP: 3597 ms
iPage shared hosting: 65 ms
A2Hosting shared hosting: 26 ms
Here’s the test program…
<?php
$rStartTime = microtime(true);
$countTo = 100000;
$a = 0;
//$countTo = $countTo * 100;
for ($x = 0; $x <= $countTo; $x++) {
$a = sqrt(pow($x, 2));
}
$rMs = floor((microtime(true) - $rStartTime) * 1000);
echo 'timer done, countTo=' . $a . ' ms=' . $rMs;
The test program is run without debugging, by entering "http://localhost/timer.php" into Firefox.
The local machine is normally blazing fast. It’s running…
Windows 8.1
XAMPP 1.8.3 (control panel v3.2.1)
Apache 2.4.4 (latest is 2.4.20)
PHP 5.5.3
Antimalware = Windows Defender
IDE = PHPStorm 10.0.2
What's making PHP run so slowly?
I found the problem was Xdebug in xampp\php\php.ini. Here're the results of trying many solutions found around the web:
Run XAMPP as adminisrator and restart server: 3617 ms
In xampp/apache/conf/httpd.conf, replace localhost with 127.0.0.1 and restart server: 3639 ms
In Windows/System32/drivers/etc/hosts, add “127.0.0.1 127.0.0.1” & “127.0.0.1 localhost” and restart Windows: 3960 ms
In Windows/System32/drivers/etc/hosts, un-comment “127.0.0.1 localhost” and restart Windows: 3659 ms
In php.ini, uncomment zend_extension = "C:\xampp\php\ext\php_eaccelerator_ts.dll" and restart server: 3643 ms
In php.ini, set xdebug.remote_enable=0: 3598 ms
In php.ini, set remote_host="localhost": 3593 ms
In php.ini, set xdebug.profiler_enable=0: 249 ms
In php.ini, comment out all Xdebug statements: 27 ms - Success!
The sad part is, I make mistakes and need Xdebug :-(
I solve my problem with xdebug idekey setting (xdebug.idekey="xdebug1"), and chrome extension xdebug helper (https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc)
*Dont forget to disable remote_autostart (xdebug.remote_autostart=0)
Only activating debug (xdebug) by request, using idekey setting, so if debug not needed php processing can be faster/normal, tonggle by button with chrome extension
I'm using xampp 1.8.3 on windows 10 64bit,
i use custom idekey, xdebug.idekey="xdebug1", same with xdebug helper setting
[XDebug]
zend_extension = "E:\xampp183\php\ext\php_xdebug.dll"
xdebug.profiler_append = 0
xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = 0
xdebug.profiler_output_dir = "E:\xampp183\tmp"
xdebug.profiler_output_name = "cachegrind.out.%t-%s"
xdebug.remote_enable = 1
xdebug.remote_autostart=0
xdebug.idekey="xdebug1"
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "127.0.0.1"
xdebug.trace_output_dir = "E:\xampp183\tmp"
xdebug.remote_log="E:\xampp183\tmp\xdebug\xdebug.log"
Now breakpoint/debug activated only if session is requsted via xdebug helper
I excluded my website folder and my xampp folder in Windows Defender and things were solved here.
I Had the same problem with xampp, and the problem was WINDOWS DEFENDER, if you disable the windows defender protection, xampp is faster (normal speed), Also you can search the xampp folder as exlusion in windows defender. these is the solution.
Running the TS (Thread Safe) version of php can slow things down a lot. TS is generally never needed, so use a NTS (Non-Thread Safe) version of php.
[Edit addition, stolen from Quora]
Thread Safe (TS) and Non-Thread Safe (TS) are the two different PHP builds available.
Thread-safety ensures that when the shared data structure is manipulated by different threads, it is free from race conditions. This version is recommended where the web server run multiple threads of execution simultaneously for different requests.
For example, in Apache server, if we use mod_php as worker MPM, thread-safe version should be used.
Non-thread-safe version on the other hand is used where PHP is installed as a CGI binary. Here every request is handled separately which removes the need of thread-safe version. Moreover, using thread-safe version here degrade the performance due to unnecessary checks for thread safety. Servers like IIS & NGINX do not need thread safe versions.
I figured out that Eclipse did not end a XDebug session properly. I solved the problem by restarting the debug session and ending it properly.
for me has been an improvement after changing all of above to change from https://localhost to https://127.0.0.1
For chrome users: I found out (after trying all hints above) that the Chrome extension "Evernote Web Clipper" is also slowing down chrome.
When loading a plain URL without any includes:
enabled / disabled Evernote Web Clipper: 0,7ms / 0,25ms
For me, mcAfee Web boost extension was the Blocker. I removed the extension and now it speeds up by 90%
If you are using mysql db within your PHP script, pls check your db connection config.
Use 127.0.0.1 instead of localhost in case of db host on windows (10).
Solved php - WAMP/XAMPP is responding very slow over localhost / wordpress
The easiest way is that go to c dirive > xamp > php folder > search php.ini > clink on top then find max_execution_time anset it to max_execution_time=300 > now restart xamp > all done :)
max_execution_time=300
After installing APC on a VPS with CentOS/Nginx/8G Ram, apc.php always shows uptime = 0 minutes, this is my apc configuration :
apc.enabled=1
apc.shm_size=512M
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.max_file_size=5M
apc.stat=0
apc.optimization=0
apc.shm_segments=1
apc.enable_cli=1
apc.cache_by_default=1
apc.include_once_override=1
I restared nginx afeter updating php.ini, the website seems to be faster than before, do you thing "uptime=0" is normal value ?
I upgrade my moodle from 2.6.4 to 2.7.1. After upgrading I've got blank (white) screen. Then I turn on debug display in config.php
$CFG->debug = 32767;
$CFG->debugdisplay = true;
After that I receive an error: Fatal error: Cannot redeclare class condition_info in /home/moodle/public_html/lib/conditionlib.php on line 105.
Then I search and found that might be a problem with opcache (https://tracker.moodle.org/browse/MDL-45797). So I follow this doc - http://docs.moodle.org/27/en/admin/environment/php_setting/opcache.enable and enable opcache in php.ini:
[opcache]
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 4000
opcache.revalidate_freq = 60
; Required for Moodle
opcache.use_cwd = 1
opcache.validate_timestamps = 1
opcache.save_comments = 1
opcache.enable_file_override = 0
; If something does not work in Moodle
;opcache.revalidate_path = 1 ; May fix problems with include paths
;opcache.mmap_base = 0x20000000 ; (Windows only) fix OPcache crashes with event id 487
; Experimental for Moodle 2.6 and later
;opcache.fast_shutdown = 1
;opcache.enable_cli = 1 ; Speeds up CLI cron
;opcache.load_comments = 0 ; May lower memory use, might not be compatible with add-ons and other apps.
Reload apache and it still doesn't work. I also try to comment out part ; If something does not work in Moodle and error still occurs. Any idea what might be wrong?
I also read that might be a problem with themes. Before I upgrade I switch theme to Clean which is default theme in 2.7.
I have ubuntu 14.04 with PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
This might be a bug or an incompatibility with the opcache system.
i would suggest to turn the opcache off: opcache.enable = 0. The opcache is only good, if everything works and you want to gain some additional performance.
restart PHP
restart Apache
Finally try one of these downloads:
2.7 - https://github.com/moodle/moodle/archive/v2.7.1.tar.gz
master [latest] - https://github.com/moodle/moodle/archive/master.zip
If the problem persists: please open a new bug report over at moodle and reference the report you found. it is clearly related.