Web Panel loading very slowly (1+ minute)

When trying to load the web panel (both beta and classic panel) it takes 1+ minutes to load. I’m stuck at a blank screen for about half a minute, then the loading animation appears and I’m stuck there for at least another minute before the panel loads. Sometimes it’s not even formatted correctly, because it took so long to load.

It worked fine before, this problem started about a week ago. I didn’t change anything in the bot settings.

No error messages in logs, no warnings in the console.

Edit: It seems like it’s working fine when connecting via an internal IP over my local network, but as soon as I try to connect with my public IP it’s slow as hell… Has anyone an idea, whats wrong? As mentioned above, it worked fine for over a year.

PhantomBot Version: Stable 2.4.2
OS Version: up-to-date Raspbian Stretch
Java Version: Java 8-191
Browser and Version (for Panel Support): Google Chrome (Win10), also tested on Safari (iOS)
Stock PhantomBot: Yes

1 Like

I had the same thing recently. It turned out that it was a connection issues with a VPS/VDS provider hubs. Technical support solved the problem instantly. Maybe you have the same issue.

UPD The provider even gifted me two weeks for free for the inconvenience :slight_smile:

I don’t have a VPS provider, since I host my Phantombot myself on my home server.

The problem still persists. Any other ideas?

BTW: I did a ping test to the external IP of the server. Result: 20ms. Not too bad…

If it works fine internally and not externally, then question the network equipment or your ISP. Ping is not always a great storyteller. That is a small packet and is not like a web socket. I typically will sniff packets with tcpdump to see what is going on with AWS servers that appear to have network connectivity issues, then I can see in real-time data in and out.

Sorry, I’m not very experienced with networking stuff… I tried sniffing packets with tcpdump, but I don’t know what the output text means. I set it to only sniff on the ports used by Phantombot, but I get a ton of messages when connecting to the web panel (hundreds of lines…).

Example (IP partly Censored):

15:28:33.959365 IP 194-XXX-XXX-60.hdsl.highway.telekom.at.50394 > Flags [P.], seq 10342:10430, ack 45167, win 1022, length 88
15:28:33.962121 IP > 194-XXX-XXX-60.hdsl.highway.telekom.at.50394: Flags [P.], seq 45167:45266, ack 10430, win 14870, length 99    
15:28:34.006240 IP 194-XXX-XXX-60.hdsl.highway.telekom.at.50394 > Flags [.], ack 45266, win 1022, length 0    

BTW, the bot reacts instantaneous to chat commands (!command to reply within milliseconds). I don’t know if that matters in this case, but I wanted to mention it…

Responsiveness via chat commands would not be relevant in this case. They’re handled differently than the panel. Your tcpdump output provided does present anything noteworthy to myself, perhaps IO can shed more light.

As a note it’s common in the US for ISP’s to disallow and cause issues with self-hosted programs (IE game servers, etc) for users without business grade service. While I’m not sure where you’re located, I did notice that you stated it worked fine for a long period of time and then randomly stopped working. Have you tried using an older bot version that you know worked? That would tell us if there’s a chance of the issue being due to an update. Have you changed any of your networking related hardware, new router or modem? Have you reached out to your ISP to inquire if anything changed on their end?

I’m living in Austria, Central Europe, and ISPs here don’t restrict network traffic for home users, as far as I know, and connections are very stable/reliable. And yes, it worked fine for over a year. Same Router, same data plan, same Phantombot version as before. I tried the nightly build last week, but that didn’t fix it. I didn’t try to downgrade to 2.4.1 though, I’ll do that later today…

Ok, same problem with 2.4.1.

Like I said before, if it works fine internally, then it is the external routing coming in. PhantomBot, or any other application, is agnostic as to where it sends and responds to traffic - it just sees an IP and sends it to the route on the local network interface then the network takes over from there. If it worked at one point and slowed down, something more than likely did change on the network (WAN or LAN).

The TCPDump is showing that the data is coming in, first 88 bytes, then replied with 99 bytes, within nanoseconds. It then got an ACK (acknowledgement of data) back from the remote - but it took it a bit longer then it did to send the data. The input was replied to in 2756 nanoseconds. The remote system took 44,119 nanoseconds to acknowledge that packet was delivered. So, PhantomBot replied quickly, remote took a while to ACK back.

You cannot completely compare Twitch as they are an outbound service which is handled differently in routing tables, firewalls, and NAT translation. An inbound connection is handled differently in the router.

You can see that, in the flags:

tcpdump Flags:

TCP Flag tcpdump Flag Meaning
SYN S Syn packet, a session establishment request.
ACK A Ack packet, acknowledge sender’s data.
FIN F Finish flag, indication of termination.
RESET R Reset, indication of immediate abort of conn.
PUSH P Push, immediate push of data from sender.
URGENT U Urgent, takes precedence over other data.
NONE A dot . Placeholder, usually used for ACK.

The P shows the push of data. The last has no flags, so is an ACK packet.

Remember, TCP is a service that requires acknowledgement that the packet was received (unlike UDP, but let us not go down that rabbit hole). It is sort of like using a radio and needing to say “OVER” to indicate that you are ready to listen and are done talking.

This is why TCP is widely used for file transferring, you need to know that every byte got there in order. UDP is typically used for video streaming because who cares if you lose a few packets, the video will just glitch a little bit if at all.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.