WebPageTest

**asperkins** · 10-29-2010, 12:56 AM

You would probably have to run vmware/virtualbox ( don't know if wine would work ).

I'm not sure how well that would work out. If you try it be sure to let us know.

How frequent do you need the job to run?

aaronpeters · 10-29-2010, 01:04 AM

(10-29-2010 12:56 AM)asperkins Wrote: You would probably have to run vmware/virtualbox ( don't know if wine would work ).

I'm not sure how well that would work out. If you try it be sure to let us know.

How frequent do you need the job to run?

Well, I am currently providing the public IE7 test node in The Netherlands for WPT.org. I want to offer the IE8 one as well.
Options:
- Buy a WinXP box ... set it up ...
- Somehow get it up & running on my LAMP server

option 2 seems like a trial & error and a hassle, but interesting to find out if it can work.

Pat > are you listening in? What are your thoughts?

andrewa · 10-29-2010, 02:02 AM

I just wanted to throw out my thanks to everyone contributing -- it's amazing how straightforward it already is to get servers up and running. I'm running a combination of servers on Amazon EC2 and Rackspace CloudServer to get some better regional representation (though still working on having some ability to determine which data center the Rackspace instance comes up in).

I wanted to add an insight that may apply to some users that depend on distributed CDNs. One caveat I've encountered with Amazon is that the DNS servers used end up making requests that appear to served out of Seattle. The CDN I use has POPs (Points of Presence) in most major cities, but when using the Amazon US East nodes, they still end up using CNAMEs pointing at the CDN POPs located in Seattle rather than on the east coast. The Rackspace servers I run correctly resolve our CNAMEs to point at POPs near to the data center as I would expect.

The workaround that I'm using is to manually override the DNS settings on the EC2 instance, and have the first DNS server point at a public DNS (such as OpenDNS) and the second pointing at the originally assigned DNS (just in case there's a need for it)

-andrew

**asperkins** · 10-29-2010, 02:12 AM

I checked a couple of my servers and they seem to be operating as expected. When requesting a resource on akamai from my ireland ec2 instance i get an ip address that shows to be correct. I get the same for my CA and VA instances.

I'll keep an eye out for this tho. I've had issues previously with some of my PCs having mis-configured DNS entries, so I know it can create some invalid numbers.

***pmeenan*** · 10-29-2010, 03:06 AM

(10-29-2010 01:04 AM)aaronpeters Wrote: Well, I am currently providing the public IE7 test node in The Netherlands for WPT.org. I want to offer the IE8 one as well.
Options:
- Buy a WinXP box ... set it up ...
- Somehow get it up & running on my LAMP server

option 2 seems like a trial & error and a hassle, but interesting to find out if it can work.

Pat > are you listening in? What are your thoughts?

Regardless of which way you go you'll need another Windows install (the licensing costs are a royal pain). You have a couple of choices:

1 - Set up another PC
2 - Run VMWare server on your LAMP box and install inside of there (would take some pretty significant testing to make sure the results are reliable)
3 - Set up a VMWare ESXi server and run both the IE7 and IE8 testers on VM's (would require some testing but I have done a bunch of testing with ESXi and it is reliable).
4 - Find a cloud provider that has a presence in the Netherlands

***pmeenan*** · 10-29-2010, 03:11 AM

(10-29-2010 02:02 AM)andrewa Wrote: I just wanted to throw out my thanks to everyone contributing -- it's amazing how straightforward it already is to get servers up and running. I'm running a combination of servers on Amazon EC2 and Rackspace CloudServer to get some better regional representation (though still working on having some ability to determine which data center the Rackspace instance comes up in).

I wanted to add an insight that may apply to some users that depend on distributed CDNs. One caveat I've encountered with Amazon is that the DNS servers used end up making requests that appear to served out of Seattle. The CDN I use has POPs (Points of Presence) in most major cities, but when using the Amazon US East nodes, they still end up using CNAMEs pointing at the CDN POPs located in Seattle rather than on the east coast. The Rackspace servers I run correctly resolve our CNAMEs to point at POPs near to the data center as I would expect.

The workaround that I'm using is to manually override the DNS settings on the EC2 instance, and have the first DNS server point at a public DNS (such as OpenDNS) and the second pointing at the originally assigned DNS (just in case there's a need for it)

-andrew

FWIW, I have some public EC2 AMI's configured that I'm doing some testing with. If it all looks good I'll make them available for people to use. I have enhanced URLBlast to auto-configure itself based on user data so the AMI's can come right up and start testing.

For the CDN issue, did you tracert to the IP's or were you trusting WebPagetest's IP lookup (it tends to not be all that reliable with CDN POP's). Which CDN provider?

Amazon's DNS servers should be anycast and available in each data center so it would largely be the CDN provider's problem to geo-locate them correctly. Switching to Google DNS might be an option but there was a thread earlier on how Akamai has problems geo-locating through Google's DNS.

Thanks,

-Pat

***pmeenan*** · 10-29-2010, 03:26 AM

btw, I just checked my East-coast instances and the RTT to Akamai is 1ms and to MaxCDN is 3ms so it looks like they are working fine for CDN geo-location.

If you want to play with them, my AMI images are documented here: http://www.webperformancecentral.com/wik...getest/EC2

I haven't looked at CloudServer yet to see if I can do the same.

Thanks,

-Pat

andrewa · 10-29-2010, 04:06 AM

(10-29-2010 03:11 AM)pmeenan Wrote:
(10-29-2010 02:02 AM)andrewa Wrote: I just wanted to throw out my thanks to everyone contributing -- it's amazing how straightforward it already is to get servers up and running. I'm running a combination of servers on Amazon EC2 and Rackspace CloudServer to get some better regional representation (though still working on having some ability to determine which data center the Rackspace instance comes up in).

I wanted to add an insight that may apply to some users that depend on distributed CDNs. One caveat I've encountered with Amazon is that the DNS servers used end up making requests that appear to served out of Seattle. The CDN I use has POPs (Points of Presence) in most major cities, but when using the Amazon US East nodes, they still end up using CNAMEs pointing at the CDN POPs located in Seattle rather than on the east coast. The Rackspace servers I run correctly resolve our CNAMEs to point at POPs near to the data center as I would expect.

The workaround that I'm using is to manually override the DNS settings on the EC2 instance, and have the first DNS server point at a public DNS (such as OpenDNS) and the second pointing at the originally assigned DNS (just in case there's a need for it)

-andrew

FWIW, I have some public EC2 AMI's configured that I'm doing some testing with. If it all looks good I'll make them available for people to use. I have enhanced URLBlast to auto-configure itself based on user data so the AMI's can come right up and start testing.

For the CDN issue, did you tracert to the IP's or were you trusting WebPagetest's IP lookup (it tends to not be all that reliable with CDN POP's). Which CDN provider?

Amazon's DNS servers should be anycast and available in each data center so it would largely be the CDN provider's problem to geo-locate them correctly. Switching to Google DNS might be an option but there was a thread earlier on how Akamai has problems geo-locating through Google's DNS.

Thanks,

-Pat

Thanks for the response. I was using nslookup, actually, which should be accurate for the response. We're using Internap's CDN product, which should geo-locate correctly.

Here's the output from nslookup, the first using the DNS provided via DHCP, and the second using OpenDNS, the third using Google DNS.

Code:

C:\Users\Administrator>nslookup www.cozi.com. 172.16.0.23

Server:  ip-172-16-0-23.ec2.internal

Address:  172.16.0.23

Non-authoritative answer:

Name:    cdce.sef004.internap.com

Address:  64.94.126.65

Aliases:  www.cozi.com

          cozicorp.http.internapcdn.net

          http.sef004.internap.com

C:\Users\Administrator>nslookup www.cozi.com. 208.67.222.222

Server:  resolver1.opendns.com

Address:  208.67.222.222

Non-authoritative answer:

Name:    cdce.wdc007.internap.com

Address:  69.88.152.250

Aliases:  www.cozi.com

          cozicorp.http.internapcdn.net

          http.wdc007.internap.com

C:\Users\Administrator>nslookup www.cozi.com. 8.8.8.8

Server:  google-public-dns-a.google.com

Address:  8.8.8.8

Non-authoritative answer:

Name:    cdce.wdc007.internap.com

Address:  69.88.152.250

Aliases:  www.cozi.com

          cozicorp.http.internapcdn.net

          http.wdc007.internap.com

The instance is running in US-East, so the Washington, DC (WDC) lookup in the second and third case is what I would expect. The Seattle (SEF) lookup in the first, seems wrong.

georgeh · 11-25-2010, 10:01 AM

I've tried to fire up the EC2 images mentioned, but I can't seem to get anything out of them.

Q1. What, exactly, are they intented to do?

Q2. How are they meant to be controlled?
- is there an Administrator password?
- is there a web-interface on some port?

**asperkins** · 11-25-2010, 10:16 AM

(11-25-2010 10:01 AM)georgeh Wrote: I've tried to fire up the EC2 images mentioned, but I can't seem to get anything out of them.

Q1. What, exactly, are they intented to do?

Q2. How are they meant to be controlled?
- is there an Administrator password?
- is there a web-interface on some port?

They are pre built and configured windows instances with the remote agent software already installed. When you fire up an instance you specify the userdata string which provides the configuration needed by the urlblast process.

A minimal example of the userdata string:

wpt_server=www.yourserver.com wpt_key=secretKey

If you fire up one instance in each region using the above userdata string then your locations.ini file would/could look like...

[locations]
1=EC2_Viginia
2=EC2_California
3=EC2_Ireland
4=EC2_Singapore
default=Dulles_VA

;
; Physical Locations
;

[EC2_Viginia]
1=ec2-us-east-IE7
2=ec2-us-east-IE8
label="Amazon EC2 East ( Viriginia )"

[EC2_California]
1=ec2-us-west-IE7
2=ec2-us-west-IE8
label="Amazon EC2 West ( California )"

[EC2_Ireland]
1=ec2-eu-west-IE7
2=ec2-eu-west-IE8
label="Amazon EC2 EU ( Ireland )"

[EC2_Singapore]
1=ec2-ap-southeast-IE7
2=ec2-ap-southeast-IE8
label="Amazon EC2 AP ( Singapore )"

;
; The individual configurations
;

[ec2-us-east-IE7]
browser=IE 7
latency=4
label="Amazon EC2 East ( Virginia )"
localDir=/var/www/html/work/jobs/ec2-us-east-IE7
key=secretKey

[ec2-us-east-IE8]
browser=IE 8
latency=4
label="Amazon EC2 East ( Virginia )"
localDir=/var/www/html/work/jobs/ec2-us-east-IE8
key=secretKey

[ec2-us-west-IE7]
browser=IE 7
latency=4
label="Amazon EC2 West ( California )"
localDir=/var/www/html/work/jobs/ec2-us-west-IE7
key=secretKey

[ec2-us-west-IE8]
browser=IE 8
latency=4
label="Amazon EC2 West ( California )"
localDir=/var/www/html/work/jobs/ec2-us-west-IE8
key=secretKey

[ec2-eu-west-IE7]
browser=IE 7
latency=4
label="Amazon EC2 EU ( Ireland )"
localDir=/var/www/html/work/jobs/ec2-eu-west-IE7
key=secretKey

[ec2-eu-west-IE8]
browser=IE 8
latency=4
label="Amazon EC2 EU ( Ireland )"
localDir=/var/www/html/work/jobs/ec2-eu-west-IE8
key=secretKey

[ec2-ap-southeast-IE7]
browser=IE 7
latency=4
label="Amazon EC2 AP ( Singapore )"
localDir=/var/www/html/work/jobs/ec2-ap-southeast-IE7
key=secretKey

[ec2-ap-southeast-IE8]
browser=IE 8
latency=4
label="Amazon EC2 AP ( Singapore )"
localDir=/var/www/html/work/jobs/ec2-ap-southeast-IE8
key=secretKey

You shouldn't need an admin interface. The instances restart automatically periodically and can be manually restarted or terminated and re instantiated if there are any issues.