Site seems to be under heavy load atm.
They should take a look at mod_pagespeed (https://developers.google.com/speed/pagespeed/module) and start using a CDN.
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 , which has a good performance.
thanks for the hint anyway. I think David already exchanged it.
Matthias
dreamhost....
~$ 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$ 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
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.
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;
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_...
In terms of comprehension for the record I would recommend instead of the source the explanation at Wikipedia: 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 :)