Varnish Archives - developed.be

If you want Laravel to show cached content from Varnish on public pages (so without a cookie), but still want to use a cookie on admin pages, and switch between them, config the following:

Put every admin page on a subdomain: admin.mysite.com

in routes.php add the following:

Route::group(array('domain' => 'admin.mysite.com'), function()
{
//admin routes
}
 
Route::group(array('domain' => 'www.mysite.com'), function()
{
//public routes
}

Set cookieless session for public pages

in app/config/session.php

  • Set ‘driver’ to ‘array’. The option “array” will not write cookies. This is what we want for the public pages.
  • Set ‘cookie’ to a decent name.

Leave everything else default.

Override the session driver for admin pages.

The Laravel Session is initialized at the very beginning of each webserver request. There’s no point in overwriting the session driver in a controller or in a route filter (as strangely suggested on the github) because the session is already loaded and initialized before the route filter kicks in.

To overwrite the session config, you have to edit bootstrap/start.php

In bootstrap/start.php

Right after this line

require $framework.'/Illuminate/Foundation/start.php';

write a code snippet that looks like this:

if(\Request::server('HTTP_HOST') == 'admin.mysite.com'){
    Config::set('session.driver', 'native');
}

By doing this we change the session.driver to “native” (so with a cookie) for the admin pages and not on the public pages.

There is one potential pitfall:

On your admin pages, every asset (css, js, image) must be called from the admin subdomain (except assets from other domains or the cloud).

On your public pages, not a single asset (css, js, image) should be called from the admin subdomain. (so don’t use a “http://admin.mysite.com/images/login.gif” on a www.mysite.com page)

Otherwise, if an assets happens to be a 404 and goes through the webserver, it might conflict or create unwanted cookies.

The above example is a stripped down version of my own implementation. You should care for authentication (I use the Sentry2 package for Laravel). With Sentry and the above setup, you also have to put the login page (or certainly the POST-action) on the admin subdomain. Otherwise the login won’t work (because it will try to write an authentication cookie on the public pages, but can’t because of the “array” session driver, so the user will never be able to login).

There might be other ways to accomplish the same result but this setup definatly works.

It felt like a Monday morning. After my alarm clock didn’t get off (+ 1 hour), I noticed there was only a train 1 hour later, so instead of arriving at half past 9, I arrived at 11 and missed the first speaker.

Lightswith + Drupal

Anyhow. I picked up the last quarter of using Drupal together with Lightswitch (= Visual Studio). Apparently not a lot of devs had interest in the subject because there were only 20 people in the room. And those who didn’t attend were right, because all the speaker could tell us was that marrying Drupal and Lightswith could only result in a divorce.

Lightswitch can create a HTML5-admin environment based on a data layer. That data layer could be your Drupal database. Nothing works out the box for Drupal because MS of course wants to integrate their software (SharePoint, Office) and not someone else’s software.

Another downsides of all these MS-Drag-And-Drop-Automatic-Data-Layer-Builder-stuff, is that when you change your database, something on the other side might break and you could end up writing the data layer yourself (as a attendee commented). Plus, the actual html output looks weak and is unusable in a serious professional environment. Don’t try this at work, pro’s!

Drupal 8 discussion panel

Three Belgian core-devs (swentel, Wim Leers, aspilicious) had a one hour Q&A hour about Drupal 8. They all had a lot to tell so the number of actual public questions was limited.

You had to know some Drupal 8 in forehand, because new projects (say WSCCI, PSR or TWIG) were discussed without being explained.

The main message was that Drupal 8 is ready to port your modules to. But, there’s still a lot of work to be done. There are still upcoming API-changes, you can’t translate a node’s title yet and there are various other big and small release blockers. But: Views should be finished. Ah!

And why Drupal 8 should be better that its processors:

  • PSR proof. PSR is a PHP coding standard. (aimed for PSR 4 however, it’s uncertain if it the project will get there)
  • Display Suite is now a core module (however, is this really such a big plus?)
  • Getting rid of the hooks in favor for a more object oriented way (however, hooks still exist)

Continue reading “DrupalCamp Leuven 2013, a brief Saturday review.”…

To be honest, I’m a bit fed up with Drupal lately. We’re stuck with an ever-growing fat Drupal6 site, and the monster doesn’t get easier to maintain. The question isn’t if we will upgrade, but to what we will upgrade. The logical upgrade to Drupal7 will be enormous because our website has over 150.000 lines of custom php-code (not mentioning css, js, themes). So moving to Drupal 7 or creating something entirely new based on a framework… I don’t dare to say how much difference in time it will make, but I do know that the new thing must be a giant step forward to what we have now.

Why moving from Drupal to a Framework?

As much as I love Drupal, the thing is… a lot of modules do kind of what I want, but they don’t do exactly what I want. Customizing a contributed module sometimes takes me as long as I would write it myself. Especially when there’s little info in the README-file or when there are hardly any comments in the code. To give you an exampe: it’s faster to lookup the url for the admin-page in the menu-hook, than to find it in the documentation or in the navigation.

Plus, what irritates me the most. When you have +75 modules, +100.000 nodes and +10 currently logged in users, the thing gets slow.. slooowww! Even with advanced caching tools such as Memcached,  view-cache or Varnish, the thing still goes slow, even on a dedicated server. No wonder: every hook is checked for each and every request.

So I’m looking for something faster and more OO-like. I have a C#-background and the way classes are mimicked in php (including inheritance, namespaces) is simply terrible. I’d dare to say Drupal goodbye, as long as Drupal 8 isn’t released an is more decent.

My comparison of PHP Frameworks

Pfhew, long introduction, but here’s my research on PHP-Frameworks. Briefly, a framework provides a set of functions and classes to help developers write code faster and more structured. Most of them implement certain design patters, of which MVC is by far the most popular. The aim of MVC is to seperate the database-talking-code (Model) from application-specific code (Controller) from html (View). It also features a URL-mapping system to set “clean url”-rules and to separate the code-files from the actual urls (eg: /bootstrap.php shouldn’t be accessible through a browser).

Some devs use the bootstrap of a CMS as a framework-starter (like my RSS-boostrap), but it should actually be the other way around: a CMS should be build on a framework. Drupal8 will (maybe) rely on parts of Symfony2, but that won’t be out till 2014.

Continue reading “PHP Frameworks, which to choose in 2013? A comparison.”…

In case you’ve installed Varnish but not Pressflow (for Drupal 6), following scenario may happen:

  1. User A logs is, gets sessionid A
  2. User A changes something and loads a new page
  3. While loading the new page, a js or css-file is being downloaded from Varnish (example: /sites/default/files/js/js_79eb17289b3a88ec931b6f4bdb728282.js)
  4. The next file that is being downloaded is a jpg. This file doesn’t come from the Varnish cache and gives a new sessionid to the user (sessionid B)
  5. The requested page is being served correctly because it was requested with sessionid A. The user is unaware that he has a new sessionid because it happened during the loading of the page elements.
  6. The user clicks on another page and sends a new request with sessionid B.
  7. Drupal checks sessionid B and sees that it the session belongs to an anonymous user. Result: the user gets an “Access Denied” and is logged out.

Solution: install Pressflow. It will stop giving sessionids to the client.

(this post only applies if you have installed Varnish)

Let’s face it: Drupal can be a snail. When you attract lots of visitors, or have a lot of content, you performance will go down. To speed up Drupal, you need to install other software on your server that will make it appear like Drupal goes faster (but in fact stays as slow).

You can do any of these or a combination of these:

  1. Use memcache. Memcache replaces the classic cache-database-tables and puts the cache in the RAM (instead of in the database). This is the fastest way of getting your data.
  2. Use nginx instead of Apache. Nginx is a lightweight webserver that can handle more traffic than Apache. While it will not make your site magically faster, it can surely help up.
  3. Code-improvements in Drupal:
    • Disable menu_rebuild every time a view is saved. Run menu_rebuild only when cache clear is explicitly asked. (this is in fact core hacking, which is wildly disapproved, but it clearly helps)
    • Rewrite heavy queries generated by Views. Views don’t make the nicest queries. Certainly complex views can be made faster when you edit the query yourself. You can do this with a module that hooks into the view.
    • Check for node_load() calls everywhere. These functions eat up memory and should be replaced where possible (a custom query could do). You wouldn’t believe what happens when you call node_load().
    • Cron:
      • inspect all the cron hooks in your Drupal installation. Decide if the tasks are really necessary, and/or edit them. You’ll notice that the cron spends most of its time with indexing the search words.
      • Use visitorstats (like Google Analytics) to see when traffic peeks. If your website peeks at noon, edit the crontab and disable cron around that time. At least all cpu will go to your visitors. (make sure there are no real important tasks to be done). Cron should run “just enough”. I set my cron to run every hour from 11PM to 7AM.
      • Drupal calls home once a day to see if there updates for modules (with fread). This action consumes cpu. I think that once a week is more than enough. Even every forthnight. You can always check for new modules manually.
    • * In order to do find bottlenecks:
      • Use the Devel module. It displays all queries that are made to the database.
      • Use XHProf. A free php-profiler developed by Facebook to find slow components. It displays function calls and generates a graph (also install Dot for that). My article on how to install XHProf.
      • If you have the possibility, use New Relic, a tool similar to XHProf, but more advanced.
  4. Boost: Boost is a Drupal module that caches entire  webpages as static html files for anonymous users. You wouldn’t believe what a boost that gives. However: take in consideration that websites with a lot of content changes will need to refresh this cache a lot. It’ll take some time to configure. Still, it doesn’t speed-up the admin-environment in any way. This article explains how to install Boost with Nginx [mysqlperformancetuning.com].
  5. Varnish: A similar, but better, approach to Boost is Varnish. Varnish also caches pages, but puts them in the RAM, while Boost uses the hard discs (and creates amounts of files). A downside of Varnish is that it’s complex to set up (you have to put it in front of your webserver) and is difficult to config. With Varnish Drupal can’t use anonymous cookies, so you have to patch your entire Drupal setup, and use “Pressflow” as Drupal core instead of the regular Drupal releases (this is just for Drupal 6). Any module that uses sessions will have to be patched. Varnish however promises what it delivers and gives a serious boost to your website and is far more advanced than Boost. My article on how to install Varnish.
  6. If you can afford it, use a seperate (database) server. Drupal generates a lot of cpu-pressure. This makes the database on the server getting less cpu. Some queries take x50 times as much time as on a non busy site. By taking the heath of the database, this should give a performance boost.

attrack

This articles covers the installation and configuration of Nginx+Varnish+Drupal6(Pressflow) and also about the Purge module.

This article assumes:

  • you are no Drupal newbie
  • you know about the default Drupal caching
  • you have some experience with Nginx (if you have Apache as webserver, this tutorial might help you too.)
  • you know what Varnish is.

Note: I’m still updating this post. It’s a bit messy right now.

Install Varnish (the easy part)

1)

curl http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add

2)

sudo su

(enter password)

3)

echo "deb http://repo.varnish-cache.org/ubuntu/ lucid varnish-2.1" >> /etc/apt/sources.list 

Note: I installed 2.1, The latest version is 3.0. You can install 3.0 by altering the above line.

(see: https://www.varnish-cache.org/installation/ubuntu )

Continue reading “Install Varnish (with Drupal and Nginx)”…