|
| 1 | +--- |
| 2 | + |
| 3 | +myst: |
| 4 | +html_meta: |
| 5 | +description: Learn how to use A/B testing on Hypernode using the NGINX split_clients module and Hypernode Managed Vhosts (HMV). |
| 6 | +title: How to configure A/B testing with Hypernode Managed Vhosts? |
| 7 | +redirect_from: |
| 8 | + |
| 9 | +* /en/hypernode/nginx/ab-testing-hmv/ |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +<!-- source: internal knowledge + nginx.org documentation --> |
| 14 | + |
| 15 | +# A/B Testing with Hypernode Managed Vhosts |
| 16 | + |
| 17 | +Hypernode Managed Vhosts (HMV) supports A/B testing by using the native NGINX `split_clients` module. This allows you to route users to different versions of your application based on a defined percentage split. |
| 18 | + |
| 19 | +This setup is useful when you want to test different codebases, features, or layouts without deploying changes to all users at once. |
| 20 | + |
| 21 | +## How A/B Testing Works |
| 22 | + |
| 23 | +The `split_clients` module assigns users to a variant based on a hashed value. This ensures: |
| 24 | + |
| 25 | +* Consistent routing for the same user |
| 26 | +* Even distribution based on percentages |
| 27 | +* No need for external tools |
| 28 | + |
| 29 | +Each user is mapped to a variant using values like: |
| 30 | + |
| 31 | +* IP address |
| 32 | +* User agent |
| 33 | +* Time-based values |
| 34 | + |
| 35 | +## Enabling A/B Testing with HMV |
| 36 | + |
| 37 | +To create an A/B testing setup, run: |
| 38 | + |
| 39 | +```bash |
| 40 | +hypernode-manage-vhosts example.com --type ab-test |
| 41 | +``` |
| 42 | + |
| 43 | +This generates the required configuration files inside: |
| 44 | + |
| 45 | +``` |
| 46 | +/data/web/nginx/example.com/ |
| 47 | +``` |
| 48 | + |
| 49 | +You will see: |
| 50 | + |
| 51 | +* http.vhost_split_clients.conf |
| 52 | +* server.ab-proxy.conf |
| 53 | + |
| 54 | +## Example Configuration |
| 55 | + |
| 56 | +### Split configuration |
| 57 | + |
| 58 | +```nginx |
| 59 | +split_clients "cache${remote_addr}${http_user_agent}${date_gmt}" $vhost_variant { |
| 60 | + 50% a.example.com; |
| 61 | + 50% b.example.com; |
| 62 | +} |
| 63 | +``` |
| 64 | + |
| 65 | +This defines a 50/50 split between two variants. |
| 66 | + |
| 67 | +### Proxy configuration |
| 68 | + |
| 69 | +```nginx |
| 70 | +location / { |
| 71 | + resolver 8.8.8.8; |
| 72 | + proxy_pass http://${vhost_variant}; |
| 73 | +} |
| 74 | +``` |
| 75 | + |
| 76 | +Requests are routed dynamically based on the assigned variant. |
| 77 | + |
| 78 | +## Setting Up Variants |
| 79 | + |
| 80 | +You must create separate vhosts for each variant: |
| 81 | + |
| 82 | +* a.example.com → version A |
| 83 | +* b.example.com → version B |
| 84 | + |
| 85 | +These should be standard vhosts using HMV: |
| 86 | + |
| 87 | +```bash |
| 88 | +hypernode-manage-vhosts a.example.com |
| 89 | +hypernode-manage-vhosts b.example.com |
| 90 | +``` |
| 91 | + |
| 92 | +Each vhost can point to a different codebase or deployment. |
| 93 | + |
| 94 | +## Custom Traffic Splits |
| 95 | + |
| 96 | +You can adjust the percentages to control traffic distribution. |
| 97 | + |
| 98 | +Example: 70/30 split |
| 99 | + |
| 100 | +```nginx |
| 101 | +split_clients "cache${remote_addr}${http_user_agent}${date_gmt}" $vhost_variant { |
| 102 | + 30% a.example.com; |
| 103 | + 70% b.example.com; |
| 104 | +} |
| 105 | +``` |
| 106 | + |
| 107 | +Example: multiple variants |
| 108 | + |
| 109 | +```nginx |
| 110 | +split_clients "cache${remote_addr}${http_user_agent}${date_gmt}" $vhost_variant { |
| 111 | + 20% a.example.com; |
| 112 | + 20% b.example.com; |
| 113 | + 20% c.example.com; |
| 114 | + 20% d.example.com; |
| 115 | + 20% e.example.com; |
| 116 | +} |
| 117 | +``` |
| 118 | + |
| 119 | +## Important Notes |
| 120 | + |
| 121 | +* The split is deterministic. The same user will consistently hit the same variant. |
| 122 | +* Changes to the split logic may reassign users. |
| 123 | +* You must ensure all variant domains are reachable and correctly configured. |
| 124 | +* DNS resolution is required for proxying, hence the resolver directive. |
| 125 | + |
| 126 | +## How the Split is Determined |
| 127 | + |
| 128 | +The input string: |
| 129 | + |
| 130 | +``` |
| 131 | +"cache${remote_addr}${http_user_agent}${date_gmt}" |
| 132 | +``` |
| 133 | + |
| 134 | +is hashed using MurmurHash2. |
| 135 | + |
| 136 | +This hash determines which percentage bucket a user falls into. |
| 137 | + |
| 138 | +Example mapping: |
| 139 | + |
| 140 | +* First 0.5% → variant A |
| 141 | +* Next 2% → variant B |
| 142 | +* Remaining → default |
| 143 | + |
| 144 | +## Troubleshooting |
| 145 | + |
| 146 | +If routing behaves unexpectedly: |
| 147 | + |
| 148 | +* Run: |
| 149 | + |
| 150 | +```bash |
| 151 | +hypernode-manage-vhosts --all |
| 152 | +``` |
| 153 | + |
| 154 | +* Verify all variant vhosts exist |
| 155 | +* Check DNS resolution |
| 156 | +* Validate nginx configuration: |
| 157 | + |
| 158 | +```bash |
| 159 | +nginx -t |
| 160 | +``` |
| 161 | + |
| 162 | +## When to Use This Setup |
| 163 | + |
| 164 | +Use this approach when: |
| 165 | + |
| 166 | +* You need infrastructure-level A/B testing |
| 167 | +* You run separate codebases per variant |
| 168 | +* You want full control without external tools |
| 169 | + |
| 170 | +Avoid this setup if: |
| 171 | + |
| 172 | +* You only need frontend experiments |
| 173 | +* You rely on analytics tools like Google Optimize |
0 commit comments