Home > Programming, Servers & Scripts > Hosting, Servers & Security

---

Replicating Voluum's redirect speed with a self-hosted tracker. (8)

---

How is this accomplished? Let's say you have a Thrive or p202 install but you want the clicks to redirect just as fast as Voluum, what's the secret? Do you need to host the tracker in multiple datacenters? Do you host multiple instances of the tracker and then use some sort of DNS load balancing to redirect the clicks through the closest datacenter from where the click originated, so in essence each tracker install will only track clicks from that geo?

I know DNSMadeEasy has something called Global Traffic Director, so I'm thinking using that, with multiple installs on different servers in different geos would accomplish it, but maybe I'm missing something.

---

This is something I'm playing with.

It's not so simple.

Yes to DNS-level load balancing. However, you need to then make all systems synchronised (read: clones of each other) so that each server hosts the same install, so that the one tracking link actually works for any install in any data center.

Synchronisation of these systems properly takes planning and quite a lot of tech know-how and has to be mindful of the performance impact that will come from trying to sync multiple systems constantly, especially when trying to also read/write from databases and track clicks at the same time.

Long story short, if you aren't prepaid to invest quite a lot of time into this, don't try.

The simpler approach would be to roll out installs on each server and use different subdomains, then set up campaigns for specific countries on the closest server (so all installs are independent).

P.S. NSOne can do DNS-level load balancing much cheaper that DNSMadeEasy. Even Route 53 can do geo-based load balancing now.

---

What Zeno said.

Plus, regards to Prosper202, I've done quite a bit of research into this as well. The codebase and architecture would have to change up a bit to enable this to happen. The main issue is synchronization of the click ids across multiple systems. Plus also making it so that you don't have to be a big brained server tech to make it all work.

We will have this capability In Prosper202 Pro, and quite a few more management systems for affiliates that really want to scale without going with a hosted SaaS solution. With our design, you'd just install p202 as you normally would on a server, and go through a linking system to link all the nodes to a central core server.

Prosper202 Pro isn't free, but the source code is still fully open and unencrypted. This is something other trackers don't provide. Which means once you have it Pro, you can use it as a base for more customization.

Side note: If you are already on Pro, don't start building anything on that code since we are doing a full rewrite and will provide an extensive API layer to work with. The advantage of this is that, any mods you create will not break when we upgrade the core codebase.

SSP: If you haven't looked at Prosper202 Pro lately, catch up on everything via this blog post http://prosper.tracking202.com/blog/...prosper202-pro
Just pushed new 1.9.6 release to the download servers. Biggest new change is the weighted split tester/rotator and the fact that you don't have to setup a cron job anymore. The auto monetizer is almost done too.

---

zeno is totaly right for an all in one solution use Route 53
if you have less time you can just setup many geos and use different domains

---

Thanks Zeno, I didn't think of the synchronization, I assumed with the load balancing set up, you can assign different campaign URLs per geo, and therefore go to the correct tracker install for that geo automatically.

I actually got motivated to do this from one of your videos, the ultimate Prosper202 server setup here:

https://www.youtube.com/watch?v=3BDOmOOtWvU

I just don't know how to accomplish that, especially the cache layer part which I didn't understand. I assume when you say to have the different "clickservers", that means different servers (VPS, dedicated, etc.) with p202 installed on it?

---

Ah cool, this setup is mainly optimized for high availability, but would suffer from the latency problem. So if you want speed it wouldn't work as needed.

The reason for this is that it uses a central database so even though you have multiple clickservers(Machines with P202 or whatever tracker you want on it) in different geos, the database will be in one geo. Some connections to the database will be slow due to that fact. Same with the cache layer, since it's one big cache.

The cache layer would be your redis or memcached. You'd want to have that located in the same geo, datacenter , or machine as the clickserver. In a perfect world, when a click hits the server, all reads would come 100% out of the cache. All writes would be saved into a queue where a worker process can pick up the data, process it and send it off to the reporting server and database.

Here a list of some of the things that can slow down the process and ways to mitigate them
1. DNS lookups - Get a fast DNS service. Check out the most current reports here. http://www.solvedns.com/dns-comparison/2015/04
2. Slow server hardware and software (webserver) - Relatively easy fix on the hardware side, but in general apache, nginx, litespeed out of the box will not be optimized for the performance you want.
3. Slow tracking software code - All the other optimizations won't matter much if your software is not efficient. Also php is easy to install and is used everywhere, but realistically for the absolute best performance you probably would be looking into something else, if you are on php then alway have the latest version or investigate using HHVP http://hhvm.com
4. Database reads - Even with SSD drives, you can't beat the performance of reading directly from memory. Either you have enough ram to fit your entire db in memory, or you cache the important parts so you don't have to read from disk. For example, the only data that really matters when a click hits a server is where should the redirect be going, so if that can be answered directly from cache/memory you will have the best performance
5. Database writes - Same as above, you will want to write to memory instead of disk. A background process can take care of saving click data to disk, this should be done aggressively enough so that little to no data is lost in the event of an unexpected server crash or reboot.

I probably missed something, but it's a good start.

---

Thanks, good stuff for me to go over, I thought it may be as simple as getting 5 or 6 $50 VPSes spread throughout the world, install Prosper on each of them and then use DNS load balancing to redirect to the correct one based on click location, and that that would be enough to give me very good redirect speeds, while having each install track just that geo's traffic.

---

Great post Nana!

That's some good info for anyone that is planning to achieve such setup.

---

Home > Programming, Servers & Scripts > Hosting, Servers & Security