How to control TTL


#1

Hi. The wiki says, “you control the TTL values for all DNS records in your domain, except your NS records”

but I couldn’t find a panel option for doing this. Help please? Thanks.


#2

The page to which you refer is misguided and should have be deleted years ago.

DreamHost lower TTL to 5 minutes during migrations, so if you need to lower TTL for a specific reason (e.g. external move), send in a request to Support to have them alter the DNS records accordingly on your behalf.


#3

Thanks. It’s not essential, just experimental. I’m configuring identical sites at two hosts in order to do performance comparisons. Although it may be a relatively minor aspect, I think that for better experimental fidelity the TTL settings should be identical.

Fortunately my other host allows user-settable TTL so I can simply make it equal to Dreamhost’s TTL (which appears to be 14400 or 4 hours – figure obtained by doing ‘dig’ at regular intervals and observing the TTL wraparound).


#4

TTL would be considered negligible when comparing hosts unless testing involves DNS changes.

I’m interested to hear more about your test setup if you can elaborate.


#5

Yes I’d be delighted to elaborate. I’m trying to chase down a puzzling anomaly. Quite likely I’m missing something obvious and feedback from the forum could save me from a wild goose chase.

The anomaly is in the ping data which I’ve been getting from my websites

(As I mentioned in another thread, I’ve been pinging since 2 of my websites were hit in January by the famous 30-second-delay-on-php bug which is still unsolved by DH afaik)

Except for a 2-day period in March (4th and 5th) when the bug returned (to another of my websites), all my sites have been consistently responsive, meaning that 99% of pings come back in less than 2 seconds.

The anomaly is in the distribution of the pings which fail to come back within 2 seconds: the data has puzzling spikes at 5 secs, 10 secs, 15 secs, 20 secs etc.

Considering only the ‘bad’ pings which fail to come back within 2 seconds, and omitting the data for March 4th and March 5th, here are the percentages (as a percentage of the bad pings) which come back within various intervals:

02 secs - 05 secs 32%
05 secs - 07 secs 52%
07 secs - 10 secs 3%
10 secs - 12 secs 4%
12 secs - 15 secs 1%
15 secs - 17 secs 7%
more than 17 secs 1%

(and yes, I am deliberately comparing intervals of 2 secs around the spikes with intervals of 3 secs between the spikes, just to show how skewed the data is).

(note also that the spike at 15 secs is much larger than the spike at 10 secs; in the raw data there are also visible spikes at 20 secs and 25 secs, but these are too small to be worth listing here).

Well, for all I know, this could be normal internet behaviour.

My first thought was that it could be something to do with TTL wraparound; maybe the extra work which the ping has to do when TTL expires involves some activity which has a natural granularity of 5 seconds.

So I added TTL data to the pings, and found that there seems to be no corellation at all between TTL expiry and badness of ping.

So I’m puzzled. I thought I’d better try to reproduce this behaviour on my other host before taking it further. Hence this thread.

Probably I should give some more detail in order to explain the issue better. The pings are all of the form

running as one of my users on a Dreamhost server, where $1 ranges over my websites and $2 varies over a few simple tests such as static html (“hello world”), minimal php (“hello world”), or some minimal sql activity (mysql_connect followed by mysql_select_db).

The spikiness of the timing data looks slightly different when php (or php with sql) is invoked but basically the figures are approximately as above whether or not php/sql are involved.


#6

5 seconds is quite a few laps of the planet. Seems more like a failsafe kicking in.

I’d have expected the PHP results to be worse than HTML (unless they’re all preloaded FastCGI targets).


#7

Yes, in the normal case PHP is slower than HTML, as expected:

considering only the ‘good’ probes (arbitrarily defined as probes which come back in less than 2 secs), the average response time from my DH server to my DH websites is

static HTML (‘hello world’): 0.05 secs
static PHP (‘hello world’): 0.08 secs
PHP+mysql_select_db: 0.09 secs

and from my other host’s server in Amsterdam to my DH websites:

static HTML (‘hello world’): 0.31 secs
static PHP (‘hello world’): 0.36 secs
PHP+mysql_select_db: 0.36 secs

The puzzle is in the ‘bad’ probes, where the distribution of response times on the DH server has spikes at 5 secs, 10 secs, etc, regardless of whether the probes are for static HTML or for PHP.

Probes to my DH websites from my other host’s server have a distribution of response times which tails off smoothly instead of having spikes.

So I suspect that what is causing the spikes is not anything to do with the responsiveness of the websites. Guessing, it seems as though there is some mechanism on the DH server which puts a waiting ‘curl’ command into a lower-priority state where it is sluggish to receive results but is given a small boost at 5 second intervals.

Here are some figures for bad probes as a percentage of all probes, as an interesting point of comparison:

From DH server to DH websites,

2 to 5 secs: 0.24%
5 to 8 secs: 0.40%
more than 8 secs: 0.14%

From Amsterdam server to DH websites,

2 to 5 secs: 0.36%
5 to 8 secs: 0.04%
more than 8 secs: 0.03%

One implication of these figures is that if a probe fails to return within 2 secs, it will probably take at least 5 secs if running on a DH server, but not if running on the other server.