|
33 | 33 | # Alternatively (or in addition) you can load all the tile sets defined in the configuration file into this virtual host |
34 | 34 | LoadTileConfigFile /etc/renderd.conf |
35 | 35 |
|
| 36 | +# Specify if mod_tile should keep tile delivery stats, which can be accessed from the URL /mod_tile |
| 37 | +# The default is On. As keeping stats needs to take a lock, this might have some performance impact, |
| 38 | +# but for nearly all intents and purposes this should be negligable and so it is safe to keep this turned on. |
| 39 | + ModTileEnableStats On |
| 40 | + |
| 41 | +# Turns on bulk mode. In bulk mode, mod_tile does not request any dirty tiles to be rerendered. Missing tiles |
| 42 | +# are always requested in the lowest priority. The default is Off. |
| 43 | + ModTileBulkMode Off |
| 44 | + |
36 | 45 | # Timeout before giving up for a tile to be rendered |
37 | 46 | ModTileRequestTimeout 3 |
38 | 47 |
|
@@ -111,20 +120,24 @@ ModTileCacheDurationLowZoom 9 518400 |
111 | 120 | ModTileCacheLastModifiedFactor 0.20 |
112 | 121 |
|
113 | 122 | ## Tile Throttling |
114 | | -## Tile scrappers can often download large numbers of tiles and overly staining tileserver resources |
| 123 | +## Tile scrapers can often download large numbers of tiles and overly strain tileserver resources |
115 | 124 | ## mod_tile therefore offers the ability to automatically throttle requests from ip addresses that have |
116 | 125 | ## requested a lot of tiles. |
117 | 126 | ## The mechanism uses a token bucket approach to shape traffic. I.e. there is an initial pool of n tiles |
118 | 127 | ## per ip that can be requested arbitrarily fast. After that this pool gets filled up at a constant rate |
119 | | -## The algorithm has to metrics. One based on overall tiles served to an ip address and a second one based on |
| 128 | +## The algorithm has two metrics. One based on overall tiles served to an ip address and a second one based on |
120 | 129 | ## the number of requests to renderd / tirex to render a new tile. |
121 | 130 |
|
122 | 131 | ## Overall enable or disable tile throttling |
123 | 132 | ModTileEnableTileThrottling Off |
124 | | -## When the tileserver is behind a proxy one can use the X-Forwarded-For http header to determin the remote IP for throttling |
125 | | -## 0: don't use X-Forwarded-For |
126 | | -## 1: Use the first address in the X-Forwarded chain, which should be the client address. However, this may not be trusted. |
127 | | -## 2: Use the last address in the X-Forwarded chain. If one uses a reverse proxy, this will be the IP address seen by the reverse proxy and can be trusted. |
| 133 | +# Specify if you want to use the connecting IP for throtteling, or use the X-Forwarded-For header to determin the |
| 134 | +# IP address to be used for tile throttling. This can be useful if you have a reverse proxy / http accellerator |
| 135 | +# in front of your tile server. |
| 136 | +# 0 - don't use X-Forward-For and allways use the IP that apache sees |
| 137 | +# 1 - use the client IP address, i.e. the first entry in the X-Forwarded-For list. This works through a cascade of proxies. |
| 138 | +# However, as the X-Forwarded-For is written by the client this is open to manipulation and can be used to circumvent the throttling |
| 139 | +# 2 - use the last specified IP in the X-Forwarded-For list. If you know all requests come through a reverse proxy |
| 140 | +# that adds an X-Forwarded-For header, you can trust this IP to be the IP the reverse proxy saw for the request |
128 | 141 | ModTileEnableTileThrottlingXForward 0 |
129 | 142 |
|
130 | 143 | ## Parameters (poolsize in tiles and topup rate in tiles per second) for throttling tile serving. |
|
0 commit comments