Dex-chan lover
- Joined
- Aug 28, 2018
- Messages
- 1,849
lately the site has been incredibly slow, are you guys getting DDOS'd again?
Website is slow
- Thread starter AMicrowave
- Start date
Active member
- Joined
- Sep 6, 2019
- Messages
- 20
I had been having this issue for 3 days or so, but now manga dex won't even load. I tried using mozilla, chrome and internet explorer but none work. I downloaded tor again, and it seems to work normally here. I don't know how it works but it seems i'll have to read manga with this browser for now.
- Joined
- May 6, 2020
- Messages
- 89
I assume you guys are using ms windows 10 or at least 7 .
See guys , the problem here tcp/ip stack from ms windows is so outdated . not even wifi 6(802.11ac) will help you . this server is based on ubuntu linux, while sucks but have far superior tcp/ip stack handling . serving an outdated stack is like us neckbearded geeks telling you how awesome a code is which will took you a while to understand . *no offense intended , that's how it made sense for me*
To solve the problem simply :
1. use vpn , set it's location to USA to where this server spawns locally thus forcing the server do "first come first serve" approach . this will help a lot in terms of speed client side but will worsen the problem for the server side A LOT. since it meant you centralize the workload on single location .
2. clear cache and do unbloating windows , use ccleaner or something to clean and search unbloating windows on yt . this should help not only bandwith but also your pc's overall performance , but doing this (unbloat windows) will void your warranty and windows license since it modify your copy and thus violating EULA .
3. open start menu , search command prompt , right-click , click run as administrator , type in your pw , type "netsh int ip reset" , press enter . it should help you for a while .
4. use linux , or better bsd which is the origin of internet and origin of OS .
5. use your android/iphone smartphone since android is a linux , and iphone is a BSD .
i myself use both Linux and BSD . so far i have no problem whatsoever in the image loading even though i am in Indonesia with slow <3MBps "internet speed" .
i hope this will help .
See guys , the problem here tcp/ip stack from ms windows is so outdated . not even wifi 6(802.11ac) will help you . this server is based on ubuntu linux, while sucks but have far superior tcp/ip stack handling . serving an outdated stack is like us neckbearded geeks telling you how awesome a code is which will took you a while to understand . *no offense intended , that's how it made sense for me*
To solve the problem simply :
1. use vpn , set it's location to USA to where this server spawns locally thus forcing the server do "first come first serve" approach . this will help a lot in terms of speed client side but will worsen the problem for the server side A LOT. since it meant you centralize the workload on single location .
2. clear cache and do unbloating windows , use ccleaner or something to clean and search unbloating windows on yt . this should help not only bandwith but also your pc's overall performance , but doing this (unbloat windows) will void your warranty and windows license since it modify your copy and thus violating EULA .
3. open start menu , search command prompt , right-click , click run as administrator , type in your pw , type "netsh int ip reset" , press enter . it should help you for a while .
4. use linux , or better bsd which is the origin of internet and origin of OS .
5. use your android/iphone smartphone since android is a linux , and iphone is a BSD .
i myself use both Linux and BSD . so far i have no problem whatsoever in the image loading even though i am in Indonesia with slow <3MBps "internet speed" .
i hope this will help .
@90bear thanks for the reply! I’m actually on an iPhone, but yes using a vpn set to US does work really well. I tested the site on my PC and it didn’t work either, so I don’t think it’s a Unix/windows thing. I’m actually in SA so I believe it’s most likely a region thing. What’s weird is that this never happened before, just with the image servers.
- Joined
- May 6, 2020
- Messages
- 89
@ffsets @Kevadu then how about trying to change channel if you're on wifi ? Some extra free bandwith is usually appreciated .
Actually the stack difference won't affect the speed , but it affect the "resolving approach" . Yo know how the faster the resolver working the faster you get served right ? Like i explained in my post before . It meant latency caused by tcp/ip stack difference will put you "on hold" while serving the easier one . This is normal since servers have limits and the tcp/ip stack will make sure you get served even if putting you "on hold" as long as you have connected in a certain latency . But even then processor that doing that resolver have also limited capability on how many process it can handle . Thus better tcp/ip stack do not always mean better speed , but it guaranteed you got served on better priority since you give less burden to the server .
There's practically nothing we can do on the server side , except you can bypass and gain server's administrator authority . If there's routing problem then you can just wait until the administrator resolved the problem . But any solution i've given should alleviate the server's burden . Less burden on the server means you guys will get faster serving .
Actually the stack difference won't affect the speed , but it affect the "resolving approach" . Yo know how the faster the resolver working the faster you get served right ? Like i explained in my post before . It meant latency caused by tcp/ip stack difference will put you "on hold" while serving the easier one . This is normal since servers have limits and the tcp/ip stack will make sure you get served even if putting you "on hold" as long as you have connected in a certain latency . But even then processor that doing that resolver have also limited capability on how many process it can handle . Thus better tcp/ip stack do not always mean better speed , but it guaranteed you got served on better priority since you give less burden to the server .
There's practically nothing we can do on the server side , except you can bypass and gain server's administrator authority . If there's routing problem then you can just wait until the administrator resolved the problem . But any solution i've given should alleviate the server's burden . Less burden on the server means you guys will get faster serving .
@90bear Everything you've said is wrong. When a server is overloaded, it puts requests in a queue to be served. Most of the time, the queue doesn't discriminate by client OS. It's first-come, first-served. If a response hasn't been received by the client after a certain amount of time, the request is timed out. It's that simple. It has nothing to do with wifi or OS. The servers are simply overloaded.
While your reasoning for it is also completely wrong, using a VPN or a different DNS server can allow you to connect to a server in another region that might not be overloaded.
The issue is site-wide and occurring for all users. All of the troubleshooting steps you've mentioned would only be useful if the slowdown was only being experienced by a single user or a small subset of users.
TL;DR: There's nothing anyone other than the site administrators can do to fix this. The only fix is to upgrade the current servers or spin up more servers to meet user demand. That's expensive and time-consuming, though. So, we'll just need to wait until the admins address the issue or until the COVID thing dies down and server load is back to normal.
Edit: Removing bloatware won't void your Windows license. Mircosoft offers a clean install tool to remove OEM bloatware. https://www.microsoft.com/en-us/software-download/windows10startfresh
WiFi 6 is 802.11ax.
BSD is based on UNIX. That alone proves it's not the origin of OS.
BSD came out in 1977. The first use of TCP/IP was in 1975. Also not the origin of the internet.
A PDU from a Windows client will be identical to a PDU from a Linux client. There is nothing in the header of a packet, segment, or frame that identifies what OS the client is using. It's possible to determine a client's OS through other means, like using javascript or looking at the client's response from a malformed data unit, but that has nothing to do with the network stack. While you talk about the Linux network stack being better than Windows, you don't point to anything in particular. Each stack has its advantages and disadvantages depending on the situation. If you want to discuss a specific deficiency of one over the other, that's fine, but it's incorrect to make a blanket statement like that.
Edit 2:
It's usually best to leave channel selection to the wireless AP rather than to select a static channel. Channel congestion can change over time. Most APs can analyze channel congestion and change the channel on the fly if there are any issues with RSSI or latency.
Your explanation about 'resolving approach' is nonsensical. I assume you're talking about congestion control. That's handled completely by the server and has nothing do to with the clients. Congestion control reduces the bandwidth allocated to each client or reduces transmission rate until the congestion has been resolved. If the transmission rate slows enough, the request will time out before it's served. It has nothing to do with the client OS.
While your reasoning for it is also completely wrong, using a VPN or a different DNS server can allow you to connect to a server in another region that might not be overloaded.
The issue is site-wide and occurring for all users. All of the troubleshooting steps you've mentioned would only be useful if the slowdown was only being experienced by a single user or a small subset of users.
TL;DR: There's nothing anyone other than the site administrators can do to fix this. The only fix is to upgrade the current servers or spin up more servers to meet user demand. That's expensive and time-consuming, though. So, we'll just need to wait until the admins address the issue or until the COVID thing dies down and server load is back to normal.
Edit: Removing bloatware won't void your Windows license. Mircosoft offers a clean install tool to remove OEM bloatware. https://www.microsoft.com/en-us/software-download/windows10startfresh
WiFi 6 is 802.11ax.
BSD is based on UNIX. That alone proves it's not the origin of OS.
BSD came out in 1977. The first use of TCP/IP was in 1975. Also not the origin of the internet.
A PDU from a Windows client will be identical to a PDU from a Linux client. There is nothing in the header of a packet, segment, or frame that identifies what OS the client is using. It's possible to determine a client's OS through other means, like using javascript or looking at the client's response from a malformed data unit, but that has nothing to do with the network stack. While you talk about the Linux network stack being better than Windows, you don't point to anything in particular. Each stack has its advantages and disadvantages depending on the situation. If you want to discuss a specific deficiency of one over the other, that's fine, but it's incorrect to make a blanket statement like that.
Edit 2:
It's usually best to leave channel selection to the wireless AP rather than to select a static channel. Channel congestion can change over time. Most APs can analyze channel congestion and change the channel on the fly if there are any issues with RSSI or latency.
Your explanation about 'resolving approach' is nonsensical. I assume you're talking about congestion control. That's handled completely by the server and has nothing do to with the clients. Congestion control reduces the bandwidth allocated to each client or reduces transmission rate until the congestion has been resolved. If the transmission rate slows enough, the request will time out before it's served. It has nothing to do with the client OS.
@AgentKuga You can try using a DNS server for another region or a VPN to connect to a server from a different region and hope that that server isn't also overloaded. Other than that, you'll just have to wait.
Similar threads
