After reinstalling the computer a few weeks ago, the other day I started to notice that my local development environment was running a little slow.
I have gone through many local development environments from using an external server on the local network, WAMP, virtual machines, creating environments with Ansible and VirtualBox, or VVV which was perhaps the one I used the longest.
But after some problems with VVV, I switched to Local by flywheel which initially used containers in a virtual machine. Its latest version, Local Lightning started and ran much faster by dispensing with the virtual machine and running the stack natively on each system.
Everything was going well until last week when I started noticing very high TTFBs of over 2 seconds.
This made it impossible to work, because certain AJAX requests had to wait a very long time and for every slightest change in the code the updates took forever. Because even if it is only two or three seconds, the code is being changed continuously and it is not feasible for a regular job.
After searching for possible causes both on the Internet and in the Local, changing some configuration options, disabling the PHP Debug, etc., I did not find any feature that returned me to normal times.
If you ran a TXT, HTML, etc. file, you could see that the TTF times were around 5 milliseconds. I then created a PHP file with a 10,000 iteration loop and HTML dump, the times were also on the order of milliseconds.
The next test was to create a new website without any plugin and with the default theme, but the times were still very high.
I switched between Apache and Nginx, between different versions of PHP and the times still didn’t go down. It was then that I decided to create a virtual machine in Hyper-V and install Ubuntu 20.4.
Once the virtual machine was booted, I installed Local and when creating a new WordPress site the times returned were between 20 and 50 milliseconds, so the problem was with the Local of the Windows 10 installation.
Fast-tracking the solution (or so I thought).
As I wanted to solve the problem quickly for a web site, I looked for an alternative to Local thinking about fixing the problem with Local afterwards.
In the great community of El Arroyo Dev(neighborhood council), Fernando Garcia Rebolledo recommended me to use Lando. Install and run, a marvel… they told me… I started with its installation and configuration and after some problems with permissions and personal SSH folder, the installation of Lando still didn’t work, one of the coolest errors I’ve ever seen 😉
Looking for information about my problems with Lando, I have seen that for response times, performance, etc. the best option was to use WSL 2 for Docker Desktop.
But after trying to force install Windows 10 version 2020 to have WSL 2, although it initially tells me everything is OK, it finally won’t let me install because of my specific configuration for one of the unresolved issues. Although it initially annoyed me, I think this is an improvement; if a Windows update gives unresolved problems with your specific configuration, it doesn’t allow you to install it.
Mind you, it seems like it worked for everyone but me 😄
I’m back to fight with Local
Due to the lack of WSL 2 for my configuration, I leave my problems with Lando for when I have WSL 2 and decide to try again to solve the Local problem.
I tested Local on another Windows 10 installation on my laptop and there I see that creating three new WordPress websites with the three available database options (MariaDB 10.4.10, MySQL 8.0.16 and MySQL 5.7.28) one of them, MySQL 8 gave very low performance times, so it was clear that the problem was with the database.
I went back to the desktop PC installation and started performing a “Poor man’s Debug 😄” as recommended by Adrian in the Stream community (or was it in a WP cafelito?).
The first thing I did was a PHP that only included the wp-config.php of WordPress and the times were high. If at wp-config.php I commented on the last line, the one that included the wp-settings.php then the times went back to 5 milliseconds.
Opening the file wp-settings.php I went directly to line 126 where the database functions are called (require_wp_db();), if I perform a die() before the function, the times remained in the 5 milliseconds, so it was evident that the problem is in the connection between PHP and the database.
Excessive times are prior to performing any consultation, before this, among many other tests, I had used Query Monitor and it gave me that the times of the database queries were low, because in reality the problem was in the connection with the database and not in the queries themselves.
The next step was to look for the problem of the slow connections and in this post from almost eight years ago was the possible answer: Connecting to MySQL from PHP is extremely slow.
Checking the configuration files of both MySQL and MariaDB showed that the --skip-name-resolve option was not active on Windows systems.
The problem came in the lookups between IPv4 and IPv6 and although the hosts file has the IP mapping in IPV4 and IPV6 from IP to localhost, PHP does not read that file in the connection with the Database.
Although there is more than one solution to this problem, the quickest, easiest and most obvious option is to modify the wp-config.php file and bypass the DNS lookup by changing localhost to 127.0 0.1
Testing the solution
To see that indeed everything works fine, I have created a PHP file with nothing from WordPress and that simply connects to the Database via localhost and without making any query. I measured TTFB times and it gave me 2.04 seconds:
Then we change the connection string to the Database by IP instead of host name and we have the desired results:
Once the change is made the database connection is 6.60 milliseconds and the WordPress execution returns a TTFB of just over 20 milliseconds.
Conclusion
When something is not working for us, we tend to look for complicated options, when perhaps the simplest and most obvious change is the solution we are looking for.
In this case it was very easy to do a PHP test in which I was including and excluding options to find the problem, but when we are in a hurry we do not look at the most obvious and we end up doing many more tests than necessary and spending double or triple the time.
Anyway this problem has brought me to a very obvious conclusion, and that is that the moment I have WSL 2 available, I will start using Lando for more than one development.
Looking at the possibilities of Lando I found it a fantastic solution and thanks to the Arroyo Dev group and its excellent community I met José Peleato and his talk José Peleato: Lando, the Docker Human friendly tool that I had missed at WordCamp Spain.
But as I said, for now I leave Lando for the moment when I have WSL 2 available.
Huge thanks to the entire Arroyo Dev community and to all the WP Cafelito members who have put up with my Lando, Local errors and Heidi(SQL) and other Dev porn conversations 😄.
