Long panel loading time when using blueprint and nebula
I installed Blueprint and 12 more extensions on the panel. But even just using themes, the panel loading speed is about 10 seconds. The panel is on a server with a channel of 1 Gbit/sec and a ping to my location of 50
Without blueprint, loading is fast there too
How to fix this?
70 Replies
Could you open up your network tab in inspect element and showcase what the exact wait is for?
I can only tell you tomorrow.
Alright!
If anything, here is the website address: 212.113.103.184:80
That loading time is instantly strange. My testing panel is located at https://void.prpl.wtf and has almost no difference between with and without Blueprint.
But did you also notice that it is very long?
Well comparing your ~14s load time with my ~2s (cacheless) load time is still a pretty huge gap.
I don't have caching either. The processor and RAM are not overloaded
Nginx works in http mode without using certificates
Caching as in browser-cache. My first load time is a bit higher than usual, but reloading my panel afterwards gives you a subsecond load time.
This is not the first time I have had this problem. It was somehow solved once, but I myself did not understand how exactly. Moreover, I tried to transfer almost all the files from that successful attempt to another host. This did not lead to success. The download was also long
My browser was used both without cache and with it. Loading is always very long
Your webserver waits 13-15 seconds to handle a request.
But why??
I have no clue, this is how long mine took. (854ms)
But why does this happen?
I have no clue.
And what can you do with this? The panel without blueprint just works fine
I tried different methods and on 10 different hostings with different capacities, up to 96 processor cores and 256 gigabytes of RAM. The result is the same everywhere
These servers were in different parts of the world. So the problem is somewhere in the settings or the code itself.
Yeah but if it was a problem with Blueprint wouldn't you think a lot of people would have reported it by now.
Blueprint has nothing to query when loading the login page, so I'm highly doubtful that stock Pterodactyl fixes this.
You are right, but what could be the problem then? How can I find its source?
Don't leave me with a 1v1 problem, please.
I just have a lot of things to do at the same time.
I don't know what is causing the problem or why it's happening.
But this is always and everywhere. Maybe I should give you access to the SSH terminal? This is not a production node, so there is no very important data there
You have to take this to your provider.
For what? The problem only occurs when installing BluePrint
I offered access to the VDS so that you could check any settings yourself
The problem is clearly in the Blueprint or in the way I configured it
Where are BluePrint settings stored?
In your panel's database.
How do I change these settings?
By either querying the database or writing code to query the database,
I have a common database with another panel, working on the subdomain panel.kyonix.com. This panel works simply on IP:Port
Could this be a problem?
Are you using something like NGINX Proxy Manager?
I don't know what this is :/
Then you probably don't use it.
I use Nginx as a web server.
NGINX Proxy Manager is a web UI for setting up web proxies.
I don't use it. But I plan to balance traffic using a reverse proxy in nginx
How can this interfere?
?
Anything sitting in-between the request and server can be causing the problem.
There is nothing between the request and the server at the moment.
DNS, hosting provider, nameservers, etc
The main panel is protected via CloudFlare, but this version is connected to the same database as the main one, but the connection is direct
Between 212.113.103.184 and NNT clients nothing. Maybe the problem is still in the database, and therefore, the general setting for all versions of the panel?
Ок
Could you try removing Nebula and checking if the loading time is still as high
Maybe I'll just give you the data to connect to the panel and you can check it yourself?
I mean you gave me the website url, there's not much more I need.
http://212.113.103.184:80
Has it gotten faster? It seems like a little bit.
Welp, identified the problem.
But loading still takes a long time?
9 seconds approximately
Normally when making a get query to the database, it takes less than 1ms to get a response.
Since your database is remote, it's taking over fifty times as long to query the database.
Let me try to change this by making the database local
redis database should also be made local?
Try keeping that remote for now
Due to the use of a translator, I did not understand the text of this message.
No
I made the database local. Loading is still slow
Try making the Redis database local as well
It didn't help either
Best to talk with your provider then
Provider of what?? I tried this on machines provided by more than 10 different providers in different parts of the world
Aeza, Play2Go, Hetzner, Amazon, Baget, REGRU and others
can you try
php artisan migrate --force
wild theory that the db is timing out trying to read bp tables
also did you make sure your load balancer you apparently have isnt timing out on a backend serverAt the moment it is not used at all. The connection is direct
After all these steps it seems to have become faster. Loading takes 7-8 seconds
After all these steps -rerun-install helped me
But how do you connect all this to that database now? The same extensions are there
It has been determined empirically that the problem is with nebula and its interaction with the database. What can be done about it?
Nebula makes multiple calls to the database. I might be able to turn these multiple calls into one, but that won't happen for the time being. The solution is probably finding a way for the panel database to be accessed without much delay.
Ping between nodes is 50 ms
I don't understand where the 12000 ms value comes from.
thats way too much for pterodactyl
max should be 5ms
However, turning off nebula the problem disappears
yes, nebula loading the config takes long because php cannot be used with such high ping
you need to either balance your database or move it to the same node
That is, set up replication?
yes
How much does a database weigh for 1000 users + 13 blueprint extensions, approximately?
less than 100mb
probably closer to 5mb
But the master-master concept would also require communication between the two databases. Wouldn't that cause the same delay?
the databases produce diffs to handle changes locally and later push them for syncing
that would make it fast for reading and medium fast for writing
I hope replication will solve the problem
As I understand it, my best bet is to use a multi-master configuration with asynchronous replication?
Sure