Cloud Platform
Signal Flow: Stack Understanding
Understanding your stack will help you when a problem arises with your website. And as we mentioned in our previous post, it's not so much if you are going to have a problem with your site, but when.
One of the best troubleshooters we ever worked with is a former sound engineer. He taught us, Follow the signal, it's all signal flow. When you are working with sound, your stack consists of amplifiers, preamps, limiters, microphones, recording devices, speakers, just to name a few.
Running a website, your stack is the combination of hardware and software that you use to deliver your website, and the signal is a web request. To understand the signal flow of your site, you will need to understand your stack. Understanding how all of the pieces fit together lets you know where to start looking for the problems.
If you can identify where the signal breaks, then you can pinpoint the location where your web request has failed. This is essential when you're troubleshooting an issue. For example, if you are getting a PDO exception on your website, you should start sniffing around database calls, not at your theme layer. Following the flow through your stack helps to identify this.
Let's use the Acquia Cloud Enterprise stack as an example.
In this example, we have two servers loaded with Varnish for caching and Nginx for load balancing. They sit in front of multiple web servers that talk to one database.
The signal flow of a web request to this stack looks like this:
As you can see, the web request signal flows through many steps. Problems can happen at any point along the way. The more complex your stack, the more places for potential problems to happen.
Note that we have greatly reduced the Drupal layer in the web request description above. Drupal has it's own complex signal flow to render even simple pages. This flow includes converting paths, constructing dynamic pages and elements such as views, and panels. Additional modules each add their own functionality to the mix, too. Drupal's signal flow is something we'd like to address in future articles.
Let's look at a specific example in which a problem can be identified by following the flow of your signal.
Your company is having a one year anniversary and they would like the "about us" page to redirect the page to special anniversary page. You have used Drupal's Redirect Module to create a permanent (301) redirect to example.com/anniversary via the user interface (this is equivalent to manually adding the redirect command in your Apache .htaccess file directly with a Redirect 301).
However! When you visit example.com/aboutus you still see the old page and are not being redirected to /anniversary.
To kick off our troubleshooting, we are going to curl the URL to see what it tells us about the signal flow of our request in our stack, using the following in the command line:
curl -SLIXGET http://example.com/aboutus
According to Wikipedia, the cURL command comes from see url. We like using curl because it allows us to make a web request and see the results all on the command line. Examining the response there can show us things that are not as easily seen through a regular, full browser.
Let's break down that command:
And here are the important parts of the response we got:
HTTP/1.1 200 OK - HTTP Status Code response 200 (OK). Normally a 200 response would be good (everything is okay!), but in this case we are looking for a 301 redirect response and it's not there. X-Cache: HIT - This means that the page was served from the Varnish cache. Looking at the signal flow of our stack, as described above, we know that Varnish is the first layer and it is still serving us our result. We added our redirect in the .htaccess file, which is an instruction set for our Apache web server. This means the request needs to make it further down the stack to Apache.
So next, we need to get a request past the cache level. We'll do that by curling in what we call a cache-buster in the URL. Like this:
curl -SLIXGET http://example.com/?cachebust1234
What's a cache-buster, you ask? Varnish caches whole pages by URL. This means that once http://example.com is cached, Varnish will then serve that page every time we ask for it in the browser. Adding /?extrastring makes it a different URL. If that URL does not match a real URL, then it would never have been requested, therefore would not be cached in Varnish. The cache-buster therefore bypasses Varnish and gets passed to Nginx, which then passes the request along to one of your Apache web servers.
We can see two important things in the results of the cache-buster query:
We are getting the result we want (the new page) when we add the cache-buster to the URL. Now we know the problem is at the Varnish level; Varnish still has the original URL in its cache. And all we need to do is purge example.com from the Varnish cache and we should be all set! This is How to manually purge a page from Acquia Cloud Varnish cache. The documentation also explains some other ways of doing it, too.
Knowing how your stack is put together and how it's signal flow works--the paths web requests and responses take in and out of it--will help you diagnose problems you encounter easier and faster. Now it's time for you to go find out how your stack is put together; it'll make you a better troubleshooter!
Cloud Platform