Ask questions about dedicated servers here and we and other users will do our best to answer them. Please also refer to the self-help section for tutorials and answers to the most commonly asked questions.
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=1 ttl=128 time=346 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=2 ttl=128 time=0.295 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=3 ttl=128 time=0.308 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=4 ttl=128 time=0.236 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=5 ttl=128 time=0.244 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=6 ttl=128 time=0.368 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=7 ttl=128 time=0.274 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=8 ttl=128 time=0.240 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=9 ttl=128 time=0.364 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=10 ttl=128 time=0.352 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=11 ttl=128 time=0.300 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=12 ttl=128 time=0.184 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=13 ttl=128 time=0.255 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=14 ttl=128 time=0.312 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=15 ttl=128 time=0.272 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=16 ttl=128 time=0.277 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=17 ttl=128 time=0.751 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=18 ttl=128 time=0.295 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=19 ttl=128 time=0.641 ms
64 bytes from nope.internap-chicago.nfoservers.com (74.91.xxx.xxx): icmp_seq=20 ttl=128 time=0.374 ms
How can I improve this? Also pinging a site offered by your webhosting service gives me this:
Yes but I'm getting undesirable effects. The bottleneck for me is the scripts I'm using to fetch images/xml with curl in a php script. When I test here: http://codepad.viper-7.com/
It is instantaneous, while it takes 5-10 seconds for the vps to do the same action. I'm just trying to think what could be doing this.
Which one? Neither of them seem unstable to me, the first ping was just an anomaly. you do realize you are talking nanoseconds when it is that low in the first ping? The second holds a constant 48.0ms for 9 straight pings, which is damn impressive traveling halfway across the country.
If a script is slow, I doubt it is a network issue, I am even more sure after you provided those ping results. The network looks to be in tip-top shape.
What else do you have running on your vds? Does top show anything hogging cpu? How about iotop?(I think thats the disk command)
Note: Bumping when you're on the first page is unnecessary. Most people that help here probably use the "View new posts" option at the top right, if they took a look and didn't reply, it is because they aren't able to assist you.
If you aren't striving for perfection then you settle for mediocrity, is how I feel about the performance. I/O is low
cpu is never hogged, although it jumps around a lot (according to htop)
The main reason I'm so upset with the performance is that the wait time for people is extremely high when compared to the send/recieving rate. It send's a css file in 1ms but is waiting around 600ms, and I have no idea why. That is the main bottleneck at this point. I'm using this:
The wait time is horrendous, time-to-first-byte is bad, and I desperately want to fix it. I've been listing reason as to what I think, but I'm probably wrong.
It sounds like you are seeing what everyone sees when they attempt to use webhosting which is some distance from there server.
many scripts and databases don't like latency at all, even something as little as 40ms. The biggest thing I see this with is MySQL databases, they don't perform well in a delayed environment.
48ms is really about as good as it can get between those locations, you may want to consider moving your server closer to Seattle.
@Kraze^NFo> Juski has a very valid point
@Juski> Got my new signature, thanks!
@Kraze^NFo> Out of context!
@Juski> Doesn't matter!
@Juski> You said I had a valid point! You can't take it back now! It's out there!
Your website there is suggesting that the bulk of the delays are happening within your application, which tells us that it or another system on your VDS (the webserver, for instance) is misconfigured/overloaded. What external resources do you have your application pulling from Seattle? If you are using a MySQL database remotely, for instance, that will have major performance implications, and you should switch to a local MySQL server ASAP.
Wait what?! The VPS has a MariaDB server on it, I was just pinging the Seattle server to compare it. All connections for MySQL are to servers in chicago, and I also have DNS resolving disabled for extra speed. The issue isn't MySQL, the issue is that the wait time upon request to the vps is extremely high! When a user loads a page, they spend 80% waiting to recieve anything from the webserver, and only 20% actually downloading the files to load the page. I need that 80% lowered significantly since it's destroying my and all my users experience!
I'm still puzzled as to why you pinged the local IP at all, and why you think that 0.3ms is not good.
Pinging a random webhosting IP was certainly confusing and it did not make much sense to do that.
From your screenshots, what I said in my last message stands. You need to look at your webserver and application stack to determine what's holding up the main page generation.
What is this script that you are using doing exactly? Is it required for that main page to load? Is it trying to pull local resources through an external IP (instead of using the loopback)? What output is it giving you?
Are your DNS servers set correctly?
Fundamentally, this is definitely about software configuration and you should be able to fix it.
That resolv.conf may have a mistake in it -- 127.0.0.1 is at the beginning. You should edit the file being used to generate this and remove it, as unless you are running a DNS server, it will make lookups very slow.
