All pages on initial site after installation super slow

[DNPage]

Hi,

I decided to try ProcessWire as a replacement for WordPress as I was impressed with its clean admin and it looked very promising. However, no matter what I've tried, I cannot get any page to display quicker than 6 seconds. I have multiple sites on my local dev environment with Windows 10/Apache 2.4/ MySQL 5.8/ PHP 7.2 and they all perform well, including a demo WordPress site, a Magento site, multiple sites built with Laravel, SLIM framework. All of them serve their pages in milliseconds whereas, out of the box, ProcessWire it taking 6 seconds per page request.

I have tried setting the siteDBConfig to 127.0.0.1 instead of localhost, 

I have tried changing my MySQL setting to bind to 127.0.0.1

I have tired changing mu host file to not use IPv6

With each of these changes and combinations of these changes, nothing improved the page serving time. The TTFB still remained above 6 seconds.

Has anyone else encountered this issue? Why would other frameworks have no issues in my environment but ProcessWire slows down so much?  Any help here would be greatly appreciated. I really don't want to use WordPress for this next project! :(
 

Dave

 

[dragan]

Well, that's just weird, and certainly not typical for PW at all (quite the opposite).

Did you check the browser console (JS errors, network panel) for hints? Apache logs? PW logs?

Is this one of the default PW installations / profiles, or did you already customize a lot?

I guess it's some weirdness in the server setup, or DB causing the lag. Perhaps you need to adjust your .htaccess file? Is it slow in the frontend and in the backend?

[DNPage]

It was the default multi-lingual site. no changes whatsoever. I just wanted to see how well it switched between languages. It worked well but as i said slow between pages. I inspected the code, and it was always waiting on the main php call - 6-7 seconds Waiting TTFB). 
Some more info: I use virtual hosts for each of the sites and the base config for each virtual host looks like this:
<VirtualHost *:80>
    ServerName xxxxxx
    DocumentRoot "C:\localhost\xxxxxx"
    <Directory  "C:\localhost\xxxxxx">
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
 

My local sites are accessed like: http:/xxxxxx  

 

[DNPage]

Sadly, I've decided to move on and work with another CMS. When other CMSs perform well right out of the box, there's only so much I can do. 

[teppo]

18 hours ago, DNPage said:

Sadly, I've decided to move on and work with another CMS. When other CMSs perform well right out of the box, there's only so much I can do. 

Sad to see you go, but this seems like a reasonable conclusion in your case ?

Regarding your issue – I've never come across anything exactly similar myself. Since we're talking about the default multi-language site profile, there's very little data to load, so my initial guess would be that the request, or perhaps the PHP process, gets stuck somewhere. In the case of PHP the file compiler (core feature originally intended to ease migration from 2.x to 3.x) comes to mind – though that probably shouldn't be the case here – while disk based sessions could be another.

Of course the database connection could also be the bottleneck, but if you're sure that it's configured properly, then I have no idea how it could be that slow. MySQL slow query log could help in ruling this issue out though.

If you still want to debug this further, you might want to give database sessions a try (they can be enabled by installing the Sessions / ProcessSessionDB module, which is bundled with the core package), and just in case specifically disable the file compiler by setting $config->moduleCompile and $config->templateCompile to false in /site/config.php.

I have no recent experience with Windows, so not sure if something there could cause the slowdown. That being said, I do know that others are running ProcessWire on Windows, so that alone shouldn't be a problem, unless it's some rather obscure configuration issue there. If other systems are working as expected then a configuration issue sounds less likely. While WordPress admittedly caters for a number of really unlikely borderline cases (including the use of the deprecated mysql PHP extension), Laravel working as expected probably means that the environment itself is properly set up.

[DNPage]

Thanks Teppo! If I decide to take on the proposed multi-lingual project in 2020, I will revisit this. I just wanted to have a fair number of options to choose from. Perhaps over the holidays I will try again but see if choosing a single language site has any performance issues in my environment. If not, I will report back for sure. 

Dave