Nova takes at least 5-10secs to load User Resources SLOW LOADING

[elsodev]

Not sure if anyone else is experiencing this but i'm running Nova on my homestead php7.2

The response times are much slower compared to a similar setup with Backpack(took approx 2 secs). User resources (default) takes approximately 9 seconds to complete load and display, even though theres no cards, actions, filters defined, only fields.

This is the same for other resources with just fields. not even eager loaded.

[peanut24]

I'm in the exact same boat, I'm using linux and my projects are served from homestead. My nova installation is extremely slow, almost unusable when resources takes up to or more than 10 seconds to load.

I have noticed that some of my colleagues that run valet on their macs is not experiencing the same, it's actually very fast on their machines, and also the one hosted installation is running fine on the server.

Another colleague who uses the same setup as me, except he assigns 4 cores to his homestead and has a SSD drive is not having issues.

How many cpu's and RAM is assigned to your homestead installation? I've moved mine up to 2 cpus and 4gb RAM but it's still not made a noticeable difference.

[elsodev]

Mine is running 3GB RAM and 2 CPUs. I doubt is the virtual machine specs problem. Hosted version(on Ubuntu 16.04, Nginx) is running fine on my end too.

Is it isolated to Homestead?

[peanut24]

It might be the virtual machine specs, because I asked again now, the 2 colleagues that say they have no speed problems are also running homestead, but they each have 4 cpus and 4gb RAM for their instances, my laptop only has 4 cores so I can't really assign more than 2 to homestead :/

I've actually considered installing linux valet because of this, but it doesn't offer everything that homestead does, and it's not easy to be running projects on multiple php versions using valet (I have some legacy projects that can't go over php 7.0)

[elsodev]

hm why is such high specs required to run nova in the first place, did your colleagues attempt to lower down their instance specs for homestead to see if the loading speed issue is there.

[Quinndark]

I also met this question.It need at least 5-10secs to load User Resources or Post Resources.

[taylorotwell]

We are unable to debug your issue without a recreatable code example.

[jonnywilliamson]

I know this is closed. I know it's almost impossible to recreate without have the actual machine in front of you, but nova is doing the same for me with 5 users in my table, in latest homestead, a click on the users tab will take 10 seconds to load.

I'm on a windows machine.

It's likely a homestead issue, but frustrating.

[davidhemphill]

Try disabling iptables on the vagrant machine. Another customer found this fixed their issue. Other than that, it's going to be very hard to diagnose a Homestead issue. I would look at their issue repo for this.

[elsodev]

Just a note, still happening with latest version 1.0.15 on Homestead only. Other Laravel 5.6 projects on my homestead works just fine.

Will attempt disabling iptables

[justutiz]

Still happening.

[atmonshi]

I have tow projects on my Homestead , one with laravel passport installed , and all requests is very slow compared with the one without passport ..

is this related ?

[DiederikvandenB]

To add on to the problem: we are experiencing the same issue. On localhost, everything is working as it should. Whenever we move the application to the servers (GKE cluster), the lagging begins.

Interestingly enough, when I copy to cURL and run the exact same request from Postman/Insomnia, the response time drops from ~2s down to around 100ms. I deduct from this that the HTTP/server setup is not the bottleneck.

I also don't think Docker is the problem, because when I mount the container locally and run the app through docker, the speed is also fine.

Somehow, Nova's frontend seems to not like something on our servers. I am really uncertain where to continue from here.

Update: inspecting the network tab closer, it is the time to first byte (TTFB) which accounts 95% of the waiting time. Does anyone have an idea what it could be?

[mvcexpert]

Unusable, 10-20 sec page loads on "resources" running local on OSX via artisan serve

[elsodev]

seems like a lot of people still experiencing the same slow problem on homestead and artisan serve. Hopefully the developers can reopen and look into this issue.

Issue still happens on latest version (1.1.7)

[tufankilicaslan]

I was experienced same issue, but I am not using Homestead, instead using Apache on Ubuntu server. After I made some debugging, i found "Policies" making the resources index page slow. Try to disable policies first, to understand the problem ( if you are storing permissions & roles on db) .

If it solves, then it's better you cache your policies / permissions. In default laravel using "file" as a cache driver. Please be sure if your storage folder have correct permissions. Alternatively you can use database or redis cache.

[DiederikvandenB]

We have been able to resolve our issue. As I mentioned, we experienced the problem when moving the deployment to Kubernetes. In our production environment, we use tracing and logging through Google. Apparently, this caused the lagging Nova requests.

While we now know what collided with Nova in our setup, I am still perplexed by the way this issue manifested itself. No other request is laggy other than the internal Nova API requests, and then only those when they were requested by Nova itself.

Unfortunately though, I doubt that this information will be beneficial to those experiencing the problem while running artisan serve. Having said that, there is definitely something strange going on.

[ndberg]

Having the same issue with vagrant/homestead and with docker/laradock too. In production with laravel forge on Ubuntu 18.04 it's not fast but okay, ~4s.

[ndberg]

After researching I found that disabling xdebug helps me about 20%, as for that I created two bash_aliases:

alias xdebug_on='sudo phpenmod xdebug; sudo service php7.2-fpm restart;'
alias xdebug_off='sudo phpdismod xdebug; sudo service php7.2-fpm restart;'

As it's a legacy app I found some ServiceProviders which I don't need for Nova, I excluded them from the Nova Requests with (in the ServiceProviders itself):

    public function boot(Request $request)
    {
        if (!\App::runningInConsole() && !$request->is('nova/*')) {
            // code
        }
    }

It's not yet fast enough, but it helped me a bit.

[f-liva]

The problem also occurs to me, both on Windows and Linux, both on Homestead and other LAMP stacks, both on VPS digitalocean.

Does anyone have any idea why Nova's internal API requests are so slow?

[f-liva]

I made a complete profiling of the issue and the reports within issue https://github.com/laravel/nova-issues/issues/1300

I hope that the new report will not be ignored like this by the development team

[digitalunityca]

Same problem. On local Homestead, 4Gb RAM, 2CPU

Dashboard page load ~10s Resource page with 500 clients - ~16s

On staging t2.micro run fast w/o issues

[ekvedaras]

We had a similar issue when production slowed down noticeably, while local and staging worked fine. The problem / solution might not apply to everybody, but worth checking if that isn't the case.

After some debugging we have found, that we have custom cards being registered in NovaServiceProvider. Now, that should be all fine except that some of them had data being passed through constructors or ->with() methods. This is all fine unless the data you provide gets loaded from DB.

So, since card registration is happening in a service provider, it means that those card objects are being built on every request Nova makes. Thus, in our case a dashboard page executed over 250 queries to fully load.

To solve that you could move data load to overriten jsonSerialize() method in your card, or preferably, load that data with ajax after the page has loaded.

Hope this gives someone a clue. You could easily check if this isn't the case for you by logging all queries executed on the slow page. Some of them might be executed needlessly many times. Add this to \App\Providers\AppServiceProvider::boot

DB::listen(function ($query) {
    logger($query->sql, [
        'bindings' => $query->bindings,
        'time' => $query->time,
    ]);
});

[digitalunityca]

DB::listen

Not worked for me :(

[dillingham]

@ekvedaras I experienced that with cards in the service provider, saw TONS of queries

Here is a workaround https://github.com/laravel/nova-issues/issues/1162

[ekvedaras]

@dillingham Nice! However, I'm sure you would get a better experience with ajax :)

[digitalunityca]

Siwtched to Docker from Homestead/Vagrant, worked as a charm.

[andre-hh]

With Docker it was also for a longer time quite slow for me. I got it very fast after doing two things:

1. Adding delegated for the shared volume (.:/var/www/html:delegated)
2. Activating opcache (with validating timestamps to still be able to do development)

[drsdre]

I find that Nova with Xdebug on Valet is realy slow, about 40+ seconds to load a page. However when Xdebug tracing is switched off (browser), it is darn quick (< 5 seconds).

I tried removal DebugBar (instead using Telescope) with Xdebug, but that hardly makes a difference.

Also tried bypassing the permission gates, also no big difference when using Xdebug.

The frontend of our application performs good with or without Xdebug.

[robbykrlos]

I'm experiencing similar issues while using Laravel v5.8.21 Laravel Nova v2.0.6

high loading times on cards, filters and lenses, even though the return result is "[]" (not using any basically). Time vary from 800 ms to 2 seconds

[badrshs]

I have same issue , Nova take more than 10 seconds to load User page , I did nothing, Only installing laravel nova , login to the system , facing the issue :)

Edit: I found that the issue happen on all the resource , not only User resource . nova will became impossible to use if there is no solution for that , it's extremely slow , the problem seems like from the-front end , because i debug the queries they are all less than 500 ms .

[badrshs]

Solved for anyone who still have the issue , disable your Xdebug and the problem is fixed

[Christophvh]

This is still a problem. Had the same problems with both Vessel (docker) and homestead. The boot-time of the application is +- 2seconds which is crazy.

Disabling Xdebug helped a bit but still very slow.

[mikebronner]

I'm having this issue as well:

That first request always takes at least 5 seconds, often 7 or more, for TTFB. I am running on DigitalOcean VPS, as well as on Laravel Vapor, behavior is the same. Oddly enough, running on Homestead with xDebug turned on, it renders out with a much short (1.25 second) delay. That's by far not good, but much better than what I'm seeing on production, and an easier pill for end-users to swallow.

[Benjacho]

I'am experiencing this issue with docker/vessel too. This is annoying.

[sp4wnx]

Still slow loading!

[sinamiandashti]

Also slow for us loading assets and js files in nova-api we are using nginx-fpm image on Amazon EKS cluster

[ibrunotome]

We have been able to resolve our issue. As I mentioned, we experienced the problem when moving the deployment to Kubernetes. In our production environment, we use tracing and logging through Google. Apparently, this caused the lagging Nova requests.

While we now know what collided with Nova in our setup, I am still perplexed by the way this issue manifested itself. No other request is laggy other than the internal Nova API requests, and then only those when they were requested by Nova itself.

Unfortunately though, I doubt that this information will be beneficial to those experiencing the problem while running artisan serve. Having said that, there is definitely something strange going on.

Hello @DiederikvandenB, can you show the steps you did? I use your package, you entire disable/uninstall it? set the LOG_CHANNEL to stderr and start to handle exceptions with another way?

[thaifani]

Try disable the xdebug i have same issue after disabling xdebug in php.ini my problem solved maybe you have xdebug.remote_enable = on in php.ini so you must convert it to xdebug.remote_enable = off

[thaifani]

Try disable the xdebug i have same issue after disabling xdebug in php.ini my problem solved maybe you have xdebug.remote_enable = on in php.ini so you must convert it to xdebug.remote_enable = off

and if you have debug configuration in phpstorm you must delete it and reConfig it

[grayaa]

@mikebronner hello, have you found a solution ? I'm having same problem with a big projetc on laravel 5.5 !

[mikebronner]

@grayaa I haven't seen this issue in some time now. I'm running on Laravel 7 with Nova 3, though.

[igorsgm]

I'm also facing the same issue on Laravel 7 + Nova 3 😕

[elsodev]

hey guys, it seems the issue only occur in homestead. I switched my env to use valet instead, the slow down issue no longer appear.

[igorsgm]

@elsodev to be honest I'm facing the issue on both homestead and valet. Taking around 5~8 seconds to load a simple Post resource list

[thaifani]

yes in localhost it slow but in server the main dashboard take 8 second but after that it fast

[grayaa]

I've just found a great solution to debug any "php", "python" or "go" application it's "blackfire", it's way more efficent than th debugbar to deeply inspect your code execution time and memory consuption it's the first time that i've ever used it and it helps alot :) this is the installation guide: https://blackfire.io/docs/up-and-running/installation Ps: you can use their 14 days trial for premium account, so you can use their full features.

[ifaniqbal]

I'm using latest Nova v2 on freshly upgraded PHP 7.4.

I can confirm that disabling Xdebug fixed the slow loading problem.

[caalvinz]

I have the same issue here. It took over 10s to load a page. That's horrible. Can some help? Appreciate.

[rvanbaalen]

Not a single solution after all these years and reports? In development, it's super slow while in production it's "workable".

[dillingham]

Not a single solution after all these years and reports? In development, it's super slow while in production it's "workable".

They can't provide a solution for users causing performance issues.. for example.. adding any queries to a service provider or in some places of resources causes huge bottlenecks.. but that's not their fault.