-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Craft3 Timeouts and Super Slow Response #966
Comments
Sorry for the adjustments to my post! I accidentally referenced the wrong existing issue in my original note. The issue I was originally attempting to follow along with is #744 For clarity - I think the strange part about this is that the codebase, DB, everything, all works great on a standard Forge setup, but fails when run locally on Valet. Hoping someone might have an idea of where I should be looking. Thanks! |
It's definitely interesting that these have Craft CMS in common.
Observations:
I suspect you've got nginx and php error logs filled with notices about problems because of this mixed up state. Fastest cleanup would include these steps:
If timeouts persist after that then I'd suggest investigating nginx/php logs and doing some application profiling (debugbar, developer toolkit) to identify what specific requests are slow (including whether it's related to PHP calls, CSS files, JS files, IMG files, or everything equally). Unfortunately I have no knowledge of Craft's inner workings to know what communications it's trying to do behind the scenes that would cause it to be slow. (Why background stuff? .... cuz I know I've seen lots of people post about Wordpress being slow/dead because it (or some plugins) do CURL calls in the background and sometimes an https/SSL issue with system config can stop that from operating correctly.) |
@drbyte Thanks for the helpful direction. I've followed the steps you outlined for cleaning up my installed PHP versions. I'm not sure how everything got all mixed up. I've stopped, unlinked, and removed the PHP versions, before adding php7.3 back via I'll end up needing all those versions for various projects. But hopefully this cleanup straightened out my brew services? Below is my latest Regarding the original issue, I'm still seeing lengthy response times, but hopefully now, I can be sure it's not my brew setup. Also, one small follow up question. When attempting to remove the various versions of PHP via
Latest Diagnosis after cleanup sw_versProductName: Mac OS X ProductVersion: 10.15.5 BuildVersion: 19F101 valet --versionLaravel Valet 2.11.0 cat ~/.config/valet/config.json{ "tld": "fsedev", "paths": [ "/Users/justenholter/.config/valet/Sites" ] } cat ~/.composer/composer.json{ "require": { "laravel/valet": "^2.10" } } composer global diagnoseChanged current directory to /Users/justenholter/.composer Checking composer.json: WARNING No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license. Checking platform settings: OK Checking git settings: OK Checking http connectivity to packagist: OK Checking https connectivity to packagist: OK Checking github.com rate limit: OK Checking disk free space: OK Checking pubkeys: FAIL Missing pubkey for tags verification Missing pubkey for dev verification Run composer self-update --update-keys to set them up Checking composer version: You are not running the latest stable version, run `composer self-update` to update (1.10.7 => 1.10.8) Composer version: 1.10.7 PHP version: 7.3.19 PHP binary path: /usr/local/Cellar/php@7.3/7.3.19/bin/php OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020 composer global outdatedChanged current directory to /Users/justenholter/.composer ls -al /etc/sudoers.d/total 16 drwxr-xr-x 4 root wheel 128 Jun 10 21:36 . drwxr-xr-x 85 root wheel 2720 Jun 23 13:31 .. -rw-r--r-- 1 root wheel 80 Jun 10 14:10 brew -rw-r--r-- 1 root wheel 83 Jun 10 14:10 valet brew configHOMEBREW_VERSION: 2.4.2 ORIGIN: https://github.com/Homebrew/brew HEAD: f7c7e2e793ed35f354974f2fcdb5fb22a3d924a3 Last commit: 3 days ago Core tap ORIGIN: https://github.com/Homebrew/homebrew-core Core tap HEAD: 136a993276adb2fc576b7afa742b8025f9c591a8 Core tap last commit: 51 minutes ago HOMEBREW_PREFIX: /usr/local HOMEBREW_MAKE_JOBS: 8 CPU: octa-core 64-bit icelake Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby Clang: 11.0 build 1103 Git: 2.24.3 => /Library/Developer/CommandLineTools/usr/bin/git Curl: 7.64.1 => /usr/bin/curl macOS: 10.15.5-x86_64 CLT: 1103.0.32.62 Xcode: N/A brew services listName Status User Plist dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist httpd stopped mysql@5.7 started justenholter /Users/justenholter/Library/LaunchAgents/homebrew.mxcl.mysql@5.7.plist nginx started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist php stopped php@7.3 started root /Library/LaunchDaemons/homebrew.mxcl.php@7.3.plist brew list --versions | grep -E "(php|nginx|dnsmasq|mariadb|mysql|mailhog|openssl)(@\d\..*)?\s"curl-openssl 7.70.0 7.71.0 dnsmasq 2.81 mysql@5.7 5.7.29 nginx 1.19.0 openssl@1.1 1.1.1g php 7.4.6_1 php@7.3 7.3.19 brew outdatedcomposer php php -vPHP 7.3.19 (cli) (built: Jun 12 2020 00:29:59) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.19, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.19, Copyright (c) 1999-2018, by Zend Technologies which -a php/usr/local/bin/php /usr/local/bin/php /usr/bin/php php --iniConfiguration File (php.ini) Path: /usr/local/etc/php/7.3 Loaded Configuration File: /usr/local/etc/php/7.3/php.ini Scan for additional .ini files in: /usr/local/etc/php/7.3/conf.d Additional .ini files parsed: /usr/local/etc/php/7.3/conf.d/ext-opcache.ini, /usr/local/etc/php/7.3/conf.d/php-memory-limits.ini nginx -vnginx version: nginx/1.19.0 curl --versioncurl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2 Release-Date: 2019-03-27 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets php --ri curlcurl ~/.composer/vendor/laravel/valet/bin/ngrok versionngrok version 2.3.35 ls -al ~/.ngrok2ls: /Users/justenholter/.ngrok2: No such file or directory brew info nginxnginx: stable 1.19.0 (bottled), HEAD HTTP(S) server and reverse proxy, and IMAP/POP3 proxy server https://nginx.org/ /usr/local/Cellar/nginx/1.19.0 (25 files, 2.1MB) * Poured from bottle on 2020-06-10 at 20:02:58 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/nginx.rb ==> Dependencies Required: openssl@1.1, pcre ==> Options --HEAD Install HEAD version ==> Caveats Docroot is: /usr/local/var/www brew info phpphp: stable 7.4.7 (bottled), HEAD General-purpose scripting language https://www.php.net/ /usr/local/Cellar/php/7.4.6_1 (519 files, 76.1MB) Poured from bottle on 2020-06-10 at 19:59:38 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/php.rb ==> Dependencies Build: httpd, pkg-config Required: apr, apr-util, argon2, aspell, autoconf, curl-openssl, freetds, freetype, gettext, glib, gmp, icu4c, jpeg, libffi, libpng, libpq, libsodium, libzip, oniguruma, openldap, openssl@1.1, sqlite, tidy-html5, unixodbc, webp ==> Options --HEAD Install HEAD version ==> Caveats To enable PHP in Apache add the following to httpd.conf and restart Apache: LoadModule php7_module /usr/local/opt/php/lib/httpd/modules/libphp7.so brew info opensslopenssl@1.1: stable 1.1.1g (bottled) [keg-only] Cryptography and SSL/TLS Toolkit https://openssl.org/ /usr/local/Cellar/openssl@1.1/1.1.1g (8,059 files, 18MB) Poured from bottle on 2020-06-10 at 16:47:28 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openssl@1.1.rb ==> Caveats A CA file has been bootstrapped using certificates from the system keychain. To add additional certificates, place .pem files in /usr/local/etc/openssl@1.1/certs openssl version -aLibreSSL 2.8.3 built on: date not available platform: information not available options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: information not available OPENSSLDIR: "/private/etc/ssl" openssl ciphersECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:GOST2012256-GOST89-GOST89:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:GOST2001-GOST89-GOST89:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA256:CAMELLIA128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA sudo nginx -tnginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful which -a php-fpm/usr/local/sbin/php-fpm /usr/sbin/php-fpm /usr/local/opt/php/sbin/php-fpm -vPHP 7.4.6 (fpm-fcgi) (built: May 29 2020 01:45:08) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.3/php-fpm.conf --test[26-Jun-2020 22:57:38] NOTICE: configuration file /usr/local/etc/php/7.3/php-fpm.conf test is successful ls -al ~/Library/LaunchAgents | grep homebrew-rw-r--r-- 1 justenholter staff 551 Jun 10 22:05 homebrew.mxcl.mysql@5.7.plist ls -al /Library/LaunchAgents | grep homebrewls -al /Library/LaunchDaemons | grep homebrew-rw-r--r-- 1 root admin 657 Jun 26 13:52 homebrew.mxcl.dnsmasq.plist -rw-r--r-- 1 root admin 571 Jun 26 20:04 homebrew.mxcl.nginx.plist -rw-r--r-- 1 root admin 636 Jun 26 20:04 homebrew.mxcl.php@7.3.plist |
Yes, things definitely look much cleaner now.
Yes that can happen from time to time. It's caused by some of the PHP files getting their ownership changed to root. It's fine to use sudo to remove the directory as indicated.
Ya, nothing stands out as specifically being caused by a mishmash of homebrew packages. I guess the next step is application profiling to find out where the lag is happening. It's worth exploring whether the lag is DNS-related too. |
Potential fix, as I was experiencing this: If you run After doing |
@chasegiunta Thanks for posting. Event after all this time, this issue is still ongoing for me. I did a quick check and unfortunately it looks like |
In your browser's Developer Tools there's a Network tab. It will show you all the resources that the browser is requesting in order to display the page, and their response codes. Failures (timeouts, forbidden/denied, etc) are what you need to investigate, specifically determining what resources are being requested and why they're not responding. |
@drbyte I will say, in my instance, it was nothing in the frontend (the delay was TTFB), and using Yii's debugger to profile database queries, etc showed up nothing substantial enough which only led me to believe the delay was happening before the request hit PHP. @justenh if you're certain though it's not dnsmasq or nginx, the Yii debug toolbar in Craft may be the next step to see if it's application/site specific. Just curious, what is your output of |
Like others who complain that some wordpress features experience timeouts, it could be that the delays are actually back-end-related, where it's trying to access another resource but encountering errors/failures. This could be a CURL misconfiguration or a certificate problem. But to troubleshoot that you'll need to know the URLs of the resources that it's failing to reach. Application profiling and network profiling may help. So might investigating application config settings and application error logs, or increasing error reporting levels on external communication attempts by the application. |
Clear description of your problem
I'm developing a Craft 3 site on Valet that constantly times out or takes a very long time to respond. The site borders on non-functional when run on Valet but when the site is pushed to Forge, it's quick and responsive.
I read through a similar issue, #744, but the thread took too many turns and was perhaps something on the user's machine.
In my case, I run Laravel projects and Craft 2 projects on the same install of Valet all day long with no issues. It seems to be isolated to Craft3, or this particular Craft3 project.
Because it runs great on Forge. I'm thinking it must be related to Valet?
It's also worth noting that
valet use php@7.3
provides the following output, but I'm not sure thatvalet diagnose
is picking up the correct version of PHP.[Updated to reference correct ticket!]
Diagnosis
sw_vers
valet --version
cat ~/.config/valet/config.json
cat ~/.composer/composer.json
composer global diagnose
composer global outdated
ls -al /etc/sudoers.d/
brew config
brew services list
brew list --versions | grep -E "(php|nginx|dnsmasq|mariadb|mysql|mailhog|openssl)(@\d\..*)?\s"
brew outdated
php -v
which -a php
php --ini
nginx -v
curl --version
php --ri curl
~/.composer/vendor/laravel/valet/bin/ngrok version
ls -al ~/.ngrok2
brew info nginx
brew info php
brew info openssl
openssl version -a
openssl ciphers
sudo nginx -t
which -a php-fpm
/usr/local/opt/php/sbin/php-fpm -v
sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.2/php-fpm.conf --test
ls -al ~/Library/LaunchAgents | grep homebrew
ls -al /Library/LaunchAgents | grep homebrew
ls -al /Library/LaunchDaemons | grep homebrew
The text was updated successfully, but these errors were encountered: