It has been some time since I posted any blog posts.
Although I have started a few I have not been keen to post them as they weren't directly related to software development.
Anyway, for those that have contacted me and are interested please find the link to the start of the varnish API project, hopefully it will be done in the next 30 days but only time will tell if that is the case.
https://github.com/DanielTurner/varnishAPI
Tuesday, 18 August 2015
Wednesday, 29 April 2015
Varnish as your API server
Over the coming weeks I will be looking at starting a little open source github based project where the aim will be to write up vcl or vmods that enable you to use Varnish and Couchbase to act as an API.
When the idea first came to me I thought I was going rather insane, but looking at the Varnish API Engine that is available now from Varnish-Cache I realized it wasn't as insane as I had imagined.
Obviously a solution like Varnish API Engine is for high end users, with plenty of cash to spend right now to replace a bunch of servers with a single instance, this engine can handle up to 20k calls per second. So if you have traffic that might be heading that way and your horizontally scaling is getting rather expensive this the kind of solution you need, you better head over to Varnish-Cache now.
I will not be reaching for these kinds of speeds but something far better than a bunch of horizontally scaled rails boxes can give you. This should be quite achievable and there are already a few vmods that are achieving a similar result
You might wonder why couchbase?
I am already familiar with Couchbase and it has master to master replication which is something quite handy under certain circumstances.... but that isn't important. Couchbase responds really quickly to multiple requests, which is going to be important as the api is going to be lean and my plan is to have the rules being served by the database then applied by the varnish engine.
We will have to see how well we can make that work.
On another note, if you aren't using varnish to accelerate your website you either have no traffic, or you probably should,
If you are interested in contributing to the work that I will be doing I would be happy to have the assistance, and will provide the github link as soon as I am not too lazy to get one.
If you are super keen why not comment?
When the idea first came to me I thought I was going rather insane, but looking at the Varnish API Engine that is available now from Varnish-Cache I realized it wasn't as insane as I had imagined.
Obviously a solution like Varnish API Engine is for high end users, with plenty of cash to spend right now to replace a bunch of servers with a single instance, this engine can handle up to 20k calls per second. So if you have traffic that might be heading that way and your horizontally scaling is getting rather expensive this the kind of solution you need, you better head over to Varnish-Cache now.
I will not be reaching for these kinds of speeds but something far better than a bunch of horizontally scaled rails boxes can give you. This should be quite achievable and there are already a few vmods that are achieving a similar result
You might wonder why couchbase?
I am already familiar with Couchbase and it has master to master replication which is something quite handy under certain circumstances.... but that isn't important. Couchbase responds really quickly to multiple requests, which is going to be important as the api is going to be lean and my plan is to have the rules being served by the database then applied by the varnish engine.
We will have to see how well we can make that work.
On another note, if you aren't using varnish to accelerate your website you either have no traffic, or you probably should,
If you are interested in contributing to the work that I will be doing I would be happy to have the assistance, and will provide the github link as soon as I am not too lazy to get one.
If you are super keen why not comment?
Tuesday, 7 April 2015
Varnish - Using GeoIP and Load Balancing to Geo-Load
Wow, what a title.
Ok, so we determined already what GeoIP wasn't used for, but as you can see, if you include MaxMind's database in your vcl configuration, and determine where the user is located you can easily see it isn't much of a stretch to quickly implement a Geo based load balancer.
The benefit of this is that the user gets served content from a physically close location, at worse case scenario you pool all the back-ends and get the user balanced not limited to country. The physically close location minimizes the time taken up by the transport layer of your web application.
This of course isn't probably going to be as good as Amazon's Route 53 technology, but you are going to move a big chunk of your audience to a server near them.
This makes varnish not only your first step out of the slow lane but several steps into a new world of speed and capacity, ensuring your product is being served up the fastest it can be in a way that could be even culturally relevant.
Ok, so we determined already what GeoIP wasn't used for, but as you can see, if you include MaxMind's database in your vcl configuration, and determine where the user is located you can easily see it isn't much of a stretch to quickly implement a Geo based load balancer.
The benefit of this is that the user gets served content from a physically close location, at worse case scenario you pool all the back-ends and get the user balanced not limited to country. The physically close location minimizes the time taken up by the transport layer of your web application.
This of course isn't probably going to be as good as Amazon's Route 53 technology, but you are going to move a big chunk of your audience to a server near them.
This makes varnish not only your first step out of the slow lane but several steps into a new world of speed and capacity, ensuring your product is being served up the fastest it can be in a way that could be even culturally relevant.
GeoIP with Varnish and Maxmind
Before I get into this I need to point out what seems to be a common misconception. GeoIP is not a great way to tell where a user is located. It isn't too bad for country, but if you want anything more granular, it will lead you down a path of horrible disappointment.
Secondly, GeoIP isn't language... it isn't!
Language is language and you can't determine language from location.
I had to point out those things because at RG we went down the path of GeoIP was king. This was, in spite of the engineers repeatedly pointing out that it wasn't accurate, and not useful for language anyway.
If you are reading this, and someone, particularly management suggested that this works you probably should point out that there are a significant number of users that this won't work for. The largest portion of these are possibly blackberry users. Yes, blackberry isn't the leading horse in the smart phone race, but in certain countries like Indonesia they are prolific. Their geoIP location ends up being somewhere in the middle of the ocean. There is no way to get a street address from there!
Ok now that is over there are certainly some uses for determining a users geoIP. Serving up content based on country, particularly if you are serving up content that can be consumed by for example someone inside of China. One may have to filter out content that would cause a firewall block.
The secret to getting geoIP to work properly in varnish is by harnessing the ability of varnish to use inline C. You read that right, inline C, right in a varnish .vcl configuration file.This will really come in handy if your development team use C in any manner already.
The best way of course to utilize this is to understand the documentation, then you can properly implement the addition.
It is probably easier to also set a header that will be accessible to your front-end code, even if you don't use it straight away, you will never know when that kind of thing will be a feature request.
Secondly, GeoIP isn't language... it isn't!
Language is language and you can't determine language from location.
I had to point out those things because at RG we went down the path of GeoIP was king. This was, in spite of the engineers repeatedly pointing out that it wasn't accurate, and not useful for language anyway.
If you are reading this, and someone, particularly management suggested that this works you probably should point out that there are a significant number of users that this won't work for. The largest portion of these are possibly blackberry users. Yes, blackberry isn't the leading horse in the smart phone race, but in certain countries like Indonesia they are prolific. Their geoIP location ends up being somewhere in the middle of the ocean. There is no way to get a street address from there!
Ok now that is over there are certainly some uses for determining a users geoIP. Serving up content based on country, particularly if you are serving up content that can be consumed by for example someone inside of China. One may have to filter out content that would cause a firewall block.
The secret to getting geoIP to work properly in varnish is by harnessing the ability of varnish to use inline C. You read that right, inline C, right in a varnish .vcl configuration file.This will really come in handy if your development team use C in any manner already.
The best way of course to utilize this is to understand the documentation, then you can properly implement the addition.
It is probably easier to also set a header that will be accessible to your front-end code, even if you don't use it straight away, you will never know when that kind of thing will be a feature request.
Varnish as a load balancer
My first varnish article - Making Websites Fast, even crappy ones I mentioned that varnish could be used not only as a cache but one of the ways it could be used is as a load balancer.
Depending on your hardware you may like to configure more caches and separate concerns with varnish, but the load you are wanting to split is when you get a cache miss, as a cache hit comes straight out of memory.
Personally I have only done this with varnish 3, and varnish 4 configuration may be different, but if it is, I am sure it is even easier.
The first stage of setting up this hardware is determining all your back-ends; I suggest this be an include file if you have automated provisioning of servers because you could then add a line in this file, and start serving load from that server quite quickly.
Ensure that you add the .probe parameters for your backend; this sets up varnish to probe that backend to determine its health.
Here is a list of the parameters, and what they do.
You can set up the director based on round robin or client. Client will allow sticky sessions with one backend.
You may want to include the weight of each machine for whatever reason; the best place to see this is the varnish documentation. However, if you aren't keen on doing this yourself I have just learned that there is a varnish plus, where you can pay for a bunch of stuff and it seems like most of the work is done for you. So that may be worth looking into.
Hopefully this covers how to use varnish to quite quickly and simply set up a load balance; I believe my next blog will be about using varnish and the geoip MaxMind to guess where your users are from.
Depending on your hardware you may like to configure more caches and separate concerns with varnish, but the load you are wanting to split is when you get a cache miss, as a cache hit comes straight out of memory.
Personally I have only done this with varnish 3, and varnish 4 configuration may be different, but if it is, I am sure it is even easier.
The first stage of setting up this hardware is determining all your back-ends; I suggest this be an include file if you have automated provisioning of servers because you could then add a line in this file, and start serving load from that server quite quickly.
Ensure that you add the .probe parameters for your backend; this sets up varnish to probe that backend to determine its health.
Here is a list of the parameters, and what they do.
- .url - This is the url to hit.
- .interval - How often to test the health.
- .timeout - How long till this server is considered timed out.
- .window - Works with threshold.
- .threshold - The number of successful requests per window the server needs to complete before the timeout to be considered alive.
You can set up the director based on round robin or client. Client will allow sticky sessions with one backend.
You may want to include the weight of each machine for whatever reason; the best place to see this is the varnish documentation. However, if you aren't keen on doing this yourself I have just learned that there is a varnish plus, where you can pay for a bunch of stuff and it seems like most of the work is done for you. So that may be worth looking into.
Hopefully this covers how to use varnish to quite quickly and simply set up a load balance; I believe my next blog will be about using varnish and the geoip MaxMind to guess where your users are from.
Sunday, 5 April 2015
Varnish - Copy & Paste, just don't.
I mentioned before how good varnish is, and it is true, it is a fantastic customizable cache which you can serve a bunch of your websites traffic straight out of memory.
The lure of more speed and getting an immediate result might make you want to Google search and copy and paste. This is a great way to have no idea what is going on with your varnish configuration, and to that end not only have a sub-optimal to disastrous result; but you definitely will have very little chance of fixing your configuration when a problem is revealed.
Varnish does pretty much exactly what you tell it to do, and if you copy someone's configuration you will have varnish doing what is right for their particular use case, or worse yet it never worked for them either. So the best way to get a good handle on what is going on is to start from scratch with your own configuration, use varnishtest and ensure that everything happens as you expect it to. Test it before it goes to production on staging environments and pay special attention to varnishlog, varnishstat and varnishtop. These are pretty neat tools that organize the same information in different ways.
Use the varnish book to figure out what is going on with varnish, seriously this resource is invaluable and when we at GR set up our first vcl this is where almost all of the knowledge was gained.
As I post more about varnish and how it can scale your web application I will not normally post configurations, because of the risk of it being copied and pasted. So, if you are adding severe speed to your web application take the time to make the configuration good, exactly what you need and varnish will reward you for it.
The lure of more speed and getting an immediate result might make you want to Google search and copy and paste. This is a great way to have no idea what is going on with your varnish configuration, and to that end not only have a sub-optimal to disastrous result; but you definitely will have very little chance of fixing your configuration when a problem is revealed.
Varnish does pretty much exactly what you tell it to do, and if you copy someone's configuration you will have varnish doing what is right for their particular use case, or worse yet it never worked for them either. So the best way to get a good handle on what is going on is to start from scratch with your own configuration, use varnishtest and ensure that everything happens as you expect it to. Test it before it goes to production on staging environments and pay special attention to varnishlog, varnishstat and varnishtop. These are pretty neat tools that organize the same information in different ways.
Use the varnish book to figure out what is going on with varnish, seriously this resource is invaluable and when we at GR set up our first vcl this is where almost all of the knowledge was gained.
As I post more about varnish and how it can scale your web application I will not normally post configurations, because of the risk of it being copied and pasted. So, if you are adding severe speed to your web application take the time to make the configuration good, exactly what you need and varnish will reward you for it.
Thursday, 2 April 2015
Varnish - Making websites fast, even crappy ones.
This blog will be an overview of varnish, its uses and how it can turn your terribly slow website into being able to easily serve traffic at the very least 10 thousand hits per second, more likely around 2 hundred thousand hits per second.
Now that is fast.
Varnish is a high end, web application accelerator, known as a caching HTTP reverse proxy. The best part about varnish is you can make it do a whole lot more than just caching.
Through configuration you can have varnish perform the act of load balancing, geo-load balancing, serving multiple front ends, language redirection, clearing of unsightly headers, cookies, device detection, just to name a few. One thing it can't do is SSL termination, but there is a relatively easy solution to that which I will cover in another post.
When we first implemented Varnish 3.0 there wasn't that much documentation, happily I see now the documentation has improved significantly. Essentially the best way to get performance out of varnish is to write your own vcl from scratch. This means you need to study, and know what your own application does, learn how to optimize it and cache it to the max. You can even use varnishtest now to unit test your vcl, so you can utilize the benefits of TDD even in your varnish configuration code.
I will provide more varnish examples and use cases in the future as this is meant to be more of an introduction. However if you are considering using varnish to accelerate your web stack I recommend it, it is so good it is even used on wordpress sites to make them less unbearable.
So varnish is the secret to scaling your crappy code, giving you time to write it properly, buy new hardware or even time while your wordpress site grows to hire a developer, I mean "Engineer" and do it all properly.
Now that is fast.
Varnish is a high end, web application accelerator, known as a caching HTTP reverse proxy. The best part about varnish is you can make it do a whole lot more than just caching.
Through configuration you can have varnish perform the act of load balancing, geo-load balancing, serving multiple front ends, language redirection, clearing of unsightly headers, cookies, device detection, just to name a few. One thing it can't do is SSL termination, but there is a relatively easy solution to that which I will cover in another post.
When we first implemented Varnish 3.0 there wasn't that much documentation, happily I see now the documentation has improved significantly. Essentially the best way to get performance out of varnish is to write your own vcl from scratch. This means you need to study, and know what your own application does, learn how to optimize it and cache it to the max. You can even use varnishtest now to unit test your vcl, so you can utilize the benefits of TDD even in your varnish configuration code.
I will provide more varnish examples and use cases in the future as this is meant to be more of an introduction. However if you are considering using varnish to accelerate your web stack I recommend it, it is so good it is even used on wordpress sites to make them less unbearable.
So varnish is the secret to scaling your crappy code, giving you time to write it properly, buy new hardware or even time while your wordpress site grows to hire a developer, I mean "Engineer" and do it all properly.
Subscribe to:
Posts (Atom)