Skip to content
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

CP slow with DevMode = 1 #5298

Open
davidhellmann opened this issue Dec 3, 2019 · 13 comments
Open

CP slow with DevMode = 1 #5298

davidhellmann opened this issue Dec 3, 2019 · 13 comments

Comments

@davidhellmann
Copy link

@davidhellmann davidhellmann commented Dec 3, 2019

Description

Can't figure out whats going wrong. But on just one project the CP is totally slow when the DevMode is enabled. If DevMode disabled it's fast. Don't know whats the problem here but I didn't know any setting whats related to this.

It's so slow. Each request takes over 1 minute
image

Additional info

  • Craft version: 3.3.16.4
  • PHP version: 7.2.20
  • Database driver & version: 8
@Mosnar

This comment has been minimized.

Copy link
Contributor

@Mosnar Mosnar commented Dec 3, 2019

@davidhellmann Is it still slow after the first load of each CP page? Craft is typically quite slow on the first load due to it needing to regenerate cpresources when things get modified or they get deleted.

@davidhellmann

This comment has been minimized.

Copy link
Author

@davidhellmann davidhellmann commented Dec 3, 2019

@Mosnar sadly on every page load. it's a bit pain currently and not usable :(

@lukeyouell

This comment has been minimized.

Copy link

@lukeyouell lukeyouell commented Dec 3, 2019

I suffer with this when working locally.

Having dev mode enabled drastically increases the time it takes to load a page.

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 3, 2019

I'm a little reticent to add in here, as this may be a red herring -- but on the other hand if it's the real situation, reporting could give a means to excite and test. Or another avenue as to what the problem really is

I've seen such long delays literally for years. Not all the time of course, and never on a web-published site. I see them locally, on the usual sort of Homestead/Vagrant VM, on latest-everything Windows 10.

  • When occurring, this happens with a vagrant reload, which re-copies from the dev environment to the VM nginx server. Usually done because vendor is different after a composer update etc.
  • The site was I think always or near so fast as expected, on a first vagrant up, and if I reboot the laptop and bring Vagrant up again entirely. Not so sure it works often if I just vagrant halt; vagrant up.
  • What's seen here has been over years, Craft version doesn't matter. So if it's the actual problem and is in Craft, it's a long-standing problem.
  • After an amount of attention, I've put this off to being some sort of Vagrant weirdness. There is often some of that in other areas, which in due course they fix.
  • I've had some clues in recent months that when it occurs, it may actually be a DNS problem.
  • I set DNS for the VMs via lines in the usual Win10 c:\windows\system32\drivers\etc\hosts, so DNS should be instant for the Craft page request, but there are other accesses potentially involved.
  • I’m more than a little fuzzy on what I saw as far as a request that went outside and hung until a long timeout, unfortunately. And it’s always possible this was something on the page to be accessed, like an image or Vue parts. There was some reason at the time I couldn't track this down.

Ok, this is what I can say. Maybe it will give some ideas.

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 3, 2019

as usual it seems, edited the post usefully after it hit your mail, more facts put in

And a p.s. -- I almost always have been running with devMode set. Of course will try turning it off if/when I see this again...

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 3, 2019

well, a few more thoughts that could be helpful

  • I've always used rsync at vagrant up scripting to load the dev state into the VM, so my issues aren't about inter-file system slowness Vagrant can have. But could be for any of you, for 'local' if on Vagrant.

  • I've remembered more about some'DNS-seeming' cases.

    • The most recent one at the least, wasn't DNS - the timeout was too long.
    • this was delay on previews, not on the main Craft CP
    • I resolved it was because a) I often configure image asset links pointing to the live server for the dev on vm, because this is much more convenient with dev/build states of Vue or React components b) in this case, the Craft server then actually being addressed was having the browser time out on asset requests, rather than returning 404 etc: something to do with caches likely/Andris's magic transform creation.
    • Fixing the server then brought back all speed.
    • there's still something that can cause long delays for the CP and any access, and if that's not the presumed Vagrant weirdness, it's still to find
@brandonkelly

This comment has been minimized.

Copy link
Member

@brandonkelly brandonkelly commented Dec 3, 2019

Not able to reproduce, but if either of you have a Blackfire account, you could try profiling the same CP request with and without Dev Mode enabled, and then compare them. That should help identify the bottleneck(s).

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 3, 2019

@davidhellmann

This comment has been minimized.

Copy link
Author

@davidhellmann davidhellmann commented Dec 4, 2019

I've no Blackfire Account :|
@brandonkelly are there some other settings beside the devmode setting that can affect the CP speed?

When I open the Debug Bar within the CP I have this error:
image

Strange :(

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Dec 4, 2019

Don't know if it's related to this, but i see something similar to the first screenshot (missing icons) when messing up site urls, e.g. with this setting in .env (both pointing to the same target):

# DEFAULT_SITE_URL="http://starter.local"
DEFAULT_SITE_URL="http://192.168.178.35:8081"

when accessing the cp with http://starter.local/admin.

Doesn't slow anything down on a WAMP installation, but maybe in other environments?

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 4, 2019

@davidhellmann David,, you have always been able to use Blackfire for free, at a very useful level. It just costs if you want full enterprise/collab features: https://support.blackfire.io/en/articles/888235-can-i-try-blackfire-for-free

However, see what I say to Werner. I tracked this down using just the Network trace in the Chrome DevTools.

@wsydney76 Werner, by your case, you are helping me remember what happened when I tracked down this long delay, where a remote server was involved. I'm fuzzy on it because I was actually deep in another issue at the time, and this sort of thing appeared to be that occasional side annoyance which a local fresh restart had always been able to send away.

I believe what happened was something like this, which may hint to David, possibly @lukeyouell :

  • I had the environmentals for the Craft server mis-set due to some inproper copying of .env.
  • I think the two in question were DEFAULT_SITE_URL as you mention, but also the likely critical one ASSET_BASE_URL
  • if I try to piece together what had happened, the ASSET_BASE_URL was fully pathed, and pointed to the wrong server, not the one where the assets would actually be provided.
  • the result then might be that Craft hung on trying to generate/provide the asset, rather than returning a 404 or 500.
  • this hang led to the full browser access timeout, which is in the one minute range

Conclusion: have a look at what you are or are not setting for ASSET_BASE_URL.

I still think there have been quirky issues with Vagrant or the rsync reload of Craft parts which could cause a similar delay. These may actually be gone by now, as I don't recall seeing that occasional hang in recent months, and were pretty clearly not involved here.

If this purely local VM variant of the problem does happen for me again (will try to excite it), will be sure to try states of devMode...

Viel Glück, natürlich

@davidhellmann

This comment has been minimized.

Copy link
Author

@davidhellmann davidhellmann commented Dec 10, 2019

Hm still slow. Someone else an other idea?

@narration-sd

This comment has been minimized.

Copy link
Contributor

@narration-sd narration-sd commented Dec 10, 2019

@davidhellmann , I wonder if you noticed that in your screenshot here, its showing that 2.7 seconds of your 3.3 sec response time is database queries?

This is of course way out of line, but what may be a reason why? A thought or two, but you have to find it:

  • Craft (Yii) devMode logging goes into RAM memory. before in the longer term it's flushed. So is it possible you haven't got enough available memory on the system where the problem occurs, maybe just marginal enougy so that devMode is enough added use to get into problems?

    Even if you've set PHP limits high enough, if there's not enough actual memory available, the operating system will go into swapping, which would then be likely to load and run the database separately from php-fpm, and then back...lots of delay for each query. This could easily happen on an underprovisioned droplet server, or similarly on a local VM running for example on one of those short-of-memory Mac laptops, or...

  • well, I thought about DNS/path environmentals again, but this seems not likely now, even though path to the DB could be involved, because even if there were a delay, it would be resolved once. Still, if resolution were long....but again, this is not so likely, and shouldn't occur on more than an initial Craft activity.

Tracking this down will require actually measuring something that relates to the delay. Brandon's suggestion of Blackfire would be very good to isolate the area, but your Yii Debug Toolbar may have done that.

You can for the memory question run top or htop to watch consumption during these long responses, setting refresh to 1 sec for instance.

Once the database issue is tamed, the remaining 0.5 sec response would be in the reasonable range for a not-too-powerful Craft server and not much caching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.