4 ms·

Site seems to be under heavy load atm.

by hypron 12y ago

uptownhr 12y ago
Yup, doesn't load for me.
- uptownhr 12y ago
  http://cl.ly/image/203P0c1u1Y12 http://cl.ly/image/203P0c1u1Y12 dreamhost....
  - themoonbus 12y ago
    What service are you using to get that information?
    - bronson 12y ago
      One way: ~$ ping -c1 piratebox.cc PING piratebox.cc (64.111.103.127): 56 data bytes 64 bytes from 64.111.103.127: icmp_seq=0 ttl=49 time=96.722 ms --- piratebox.cc ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 96.722/96.722/96.722/0.000 ms ~$ nslookup 64.111.103.127 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: 127.103.111.64.in-addr.arpa name = ps43705.dreamhost.com. Authoritative answers can be found from: 103.111.64.in-addr.arpa nameserver = ns3.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns1.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns2.dreamhost.com. ns1.dreamhost.com internet address = 66.33.206.206 ns2.dreamhost.com internet address = 208.97.182.10 ns3.dreamhost.com internet address = 66.33.216.216
      - contingencies 12y ago
        Heh, pre-webschool :) While we're teaching. $ whois 64.111.103.1 # Note: IP!=same, similar is ok NetRange: 64.111.96.0 - 64.111.127.255 CIDR: 64.111.96.0/19 OriginAS: AS26347 NetName: DREAMHOST-BLK4 NetHandle: NET-64-111-96-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation RegDate: 2005-03-07 Updated: 2013-01-18 Ref: http://whois.arin.net/rest/net/NET-64-111-96-0-1 http://whois.arin.net/rest/net/NET-64-111-96-0-1 The above shows us that the IP address range has been owned by Dreamhost since 2005. $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops traceroute to 64.111.103.1 (64.111.103.1), 64 hops max, 52 byte packets 16 te0-0-2-0.nr11.b037327-0.iad02.atlas.cogentco.com (154.24.15.62) 150.006 ms 112.416 ms 111.521 ms 17 38.122.62.254 (38.122.62.254) 110.817 ms 111.131 ms 113.563 ms 18 ip-208-113-156-8.dreamhost.com (208.113.156.8) 122.604 ms 119.393 ms 120.720 ms 19 ip-208-113-156-14.dreamhost.com (208.113.156.14) 118.675 ms 116.344 ms 116.236 ms 20 ps43497.dreamhost.com (64.111.103.1) 165.690 ms 111.885 ms 119.339 ms This shows you the carrier in use leading to the facility (cogentco). Often facilities without reverse DNS (apparently in the final hop) or without own IP ranges (as we discovered above Dreamhost has) can still be determined without actually passing traffic by reading the reverse DNS information on the closest border hop on their carrier. In this case we don't get lucky with that technique, since #17 is not showing any reverse DNS. Beyond the above you can start looking at AS-driven routing records, physical network layouts, internet historical information, etc. before resorting to more active probes.
        pyre 12y ago
        > $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops HARD MODE: Is is actually 'hiding' those hops, or does it not even look for them? Using Apple's `traceroute.c`[1]: case 'M': /* FreeBSD compat. */ first_ttl = str2val(optarg, "first ttl", 1, 255); break; Looks like it's just bumping up the value of the first TTL. Note: For those not in the know, traceroute works by adjusting the TTL (time-to-live) value on the packet it sends out. The TTL is basically the max number of hops that the packet can take. Each 'hop' decrements the TTL value, until it reaches the destination or TTL == 0. If the TTL == 0 before it gets to the destination, then the packet it sent back as rejected. [1] http://www.opensource.apple.com/source/network_cmds/network_cmds-307.0.1/traceroute.tproj/traceroute.c http://www.opensource.apple.com/source/network_cmds/network_...
        contingencies 12y ago
        Heh! You wouldn't need to check the code to validate the execution flow unless you're on a first-world network and so used to them that latency becomes unnoticed! In terms of comprehension for the record I would recommend instead of the source the explanation at Wikipedia: https://en.wikipedia.org/wiki/Traceroute https://en.wikipedia.org/wiki/Traceroute For awhile it used to be that people would write their own traceroute implementation as a rite of passage. As a joke, back in the 1990s, Julian Assange took it one step further and used to spoof responses to traceroutes in order send a fake route back to the querying node, indicating that his systems were somehow affiliated with important government or military entities. Excellent sense of humor :)
jonathanmd 12y ago
It could just be the 3.1 MB image getting served from Apache. 3888 × 2592 might be a tiny bit too large for a preview image. They should take a look at mod_pagespeed (https://developers.google.com/speed/pagespeed/module https://developers.google.com/speed/pagespeed/module) and start using a CDN.
- MaStr 12y ago
  Well, that costs bandwith, but wasn't the issue. The issue was the cpu power. The VPS hadn't got enough cpu time for fullfilling all these requests. The machine reportet 8 cores, but load didn't cross the 4 - mark. Memory is 4GB, but that was more then enough. On the top list you were able to clearly verify the php processes running and trying to fullfill the request. We swapped to my provider http://net-build.net http://net-build.net , which has a good performance. thanks for the hint anyway. I think David already exchanged it. Matthias

Site seems to be under heavy load atm.

by hypron 12y ago

Site seems to be under heavy load atm.

uptownhr 12y ago

Yup, doesn't load for me.

uptownhr 12y ago
http://cl.ly/image/203P0c1u1Y12 http://cl.ly/image/203P0c1u1Y12 dreamhost....
- themoonbus 12y ago
  What service are you using to get that information?
  - bronson 12y ago
    One way: ~$ ping -c1 piratebox.cc PING piratebox.cc (64.111.103.127): 56 data bytes 64 bytes from 64.111.103.127: icmp_seq=0 ttl=49 time=96.722 ms --- piratebox.cc ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 96.722/96.722/96.722/0.000 ms ~$ nslookup 64.111.103.127 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: 127.103.111.64.in-addr.arpa name = ps43705.dreamhost.com. Authoritative answers can be found from: 103.111.64.in-addr.arpa nameserver = ns3.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns1.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns2.dreamhost.com. ns1.dreamhost.com internet address = 66.33.206.206 ns2.dreamhost.com internet address = 208.97.182.10 ns3.dreamhost.com internet address = 66.33.216.216
    - contingencies 12y ago
      Heh, pre-webschool :) While we're teaching. $ whois 64.111.103.1 # Note: IP!=same, similar is ok NetRange: 64.111.96.0 - 64.111.127.255 CIDR: 64.111.96.0/19 OriginAS: AS26347 NetName: DREAMHOST-BLK4 NetHandle: NET-64-111-96-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation RegDate: 2005-03-07 Updated: 2013-01-18 Ref: http://whois.arin.net/rest/net/NET-64-111-96-0-1 http://whois.arin.net/rest/net/NET-64-111-96-0-1 The above shows us that the IP address range has been owned by Dreamhost since 2005. $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops traceroute to 64.111.103.1 (64.111.103.1), 64 hops max, 52 byte packets 16 te0-0-2-0.nr11.b037327-0.iad02.atlas.cogentco.com (154.24.15.62) 150.006 ms 112.416 ms 111.521 ms 17 38.122.62.254 (38.122.62.254) 110.817 ms 111.131 ms 113.563 ms 18 ip-208-113-156-8.dreamhost.com (208.113.156.8) 122.604 ms 119.393 ms 120.720 ms 19 ip-208-113-156-14.dreamhost.com (208.113.156.14) 118.675 ms 116.344 ms 116.236 ms 20 ps43497.dreamhost.com (64.111.103.1) 165.690 ms 111.885 ms 119.339 ms This shows you the carrier in use leading to the facility (cogentco). Often facilities without reverse DNS (apparently in the final hop) or without own IP ranges (as we discovered above Dreamhost has) can still be determined without actually passing traffic by reading the reverse DNS information on the closest border hop on their carrier. In this case we don't get lucky with that technique, since #17 is not showing any reverse DNS. Beyond the above you can start looking at AS-driven routing records, physical network layouts, internet historical information, etc. before resorting to more active probes.
      - pyre 12y ago
        > $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops HARD MODE: Is is actually 'hiding' those hops, or does it not even look for them? Using Apple's `traceroute.c`[1]: case 'M': /* FreeBSD compat. */ first_ttl = str2val(optarg, "first ttl", 1, 255); break; Looks like it's just bumping up the value of the first TTL. Note: For those not in the know, traceroute works by adjusting the TTL (time-to-live) value on the packet it sends out. The TTL is basically the max number of hops that the packet can take. Each 'hop' decrements the TTL value, until it reaches the destination or TTL == 0. If the TTL == 0 before it gets to the destination, then the packet it sent back as rejected. [1] http://www.opensource.apple.com/source/network_cmds/network_cmds-307.0.1/traceroute.tproj/traceroute.c http://www.opensource.apple.com/source/network_cmds/network_...
        contingencies 12y ago
        Heh! You wouldn't need to check the code to validate the execution flow unless you're on a first-world network and so used to them that latency becomes unnoticed! In terms of comprehension for the record I would recommend instead of the source the explanation at Wikipedia: https://en.wikipedia.org/wiki/Traceroute https://en.wikipedia.org/wiki/Traceroute For awhile it used to be that people would write their own traceroute implementation as a rite of passage. As a joke, back in the 1990s, Julian Assange took it one step further and used to spoof responses to traceroutes in order send a fake route back to the querying node, indicating that his systems were somehow affiliated with important government or military entities. Excellent sense of humor :)

jonathanmd 12y ago

It could just be the 3.1 MB image getting served from Apache. 3888 × 2592 might be a tiny bit too large for a preview image. They should take a look at mod_pagespeed (https://developers.google.com/speed/pagespeed/module https://developers.google.com/speed/pagespeed/module) and start using a CDN.

MaStr 12y ago
Well, that costs bandwith, but wasn't the issue. The issue was the cpu power. The VPS hadn't got enough cpu time for fullfilling all these requests. The machine reportet 8 cores, but load didn't cross the 4 - mark. Memory is 4GB, but that was more then enough. On the top list you were able to clearly verify the php processes running and trying to fullfill the request. We swapped to my provider http://net-build.net http://net-build.net , which has a good performance. thanks for the hint anyway. I think David already exchanged it. Matthias