Category Archives: Web technology

Where have I been? Drupal Websites, self promotion, & Greek Verbs….

Posted on by

The blog has been quiet for a few days. I have been busy assembling a website advertising web development services. Along with a friend who is a Java developer, we are calling our business Digit Professionals. We are focusing on offering Drupal websites. WordPress (which is used for this blog) is ridiculously easy to set up and maintain, but a bit limited unless one uses loads of plugins and customisation. Besides I still have the impression that a WordPress site always looks like a WordPress site, and it is difficult to put one’s finger on why that should be so.

Self promotion is essential. I often think the Classics as a whole would benefit if more Classicists had a good home page where they could interact with the wider public, as well as with professional colleagues. But of course it all takes time.

What else have I been up to? Well, I have been revising Greek verbs. It is nice that the paradigm of luō starts on page 100 of Goodwin: easy to remember. But I started by reading the various tense systems which he sets out, and which I never recall anyone teaching.

The fact I need to revise Greek verbs probably means I am not reading enough Greek! But how many Classicists will admit to not needing to revise Greek verbs? My guess as that those who never need to are in the minority.

Web tech note–Why and how I downgraded from Varnish 3 to 2

Aside

Reply

Sometimes it seems to make sense to get the latest version of software you are using, especially if the upgrade is free! In the case of Varnish caching reverse proxy, it is not a good idea, unless you are running a complex installtion which requires the newer version’s features. This site is being served but not cached by Varnish. However, several Drupal sites on the same server are being cached by Varnish. For Varnish 2 there are ready-made configuration files (in Varnish’s native VCL configuration language) such as that from Pressflow. For Varnish 3 you are on your own.

The VCL syntax changed a bit from Varnish 2.0 to 2.1 but getting the config file working is not too hard. Getting Varnish 3 working with Drupal is a royal pain, and you are pretty much going to have take responsibility for writing your own VCL file. Once it is working, for a simple installation, it is if anything less efficient than Varnish 2. This is all discussed on the Drupal forum. With most of these config files, even when you get them to work so that caching (albeit some say caching less well than Varnish 2), logging in to your Drupal (or WordPress) site can break.

Upgrading is easy. Install the rpm and hit yum update varnish or yum install varnish. Yum might even find it without installing the rpm. Downgrading is more tricky.

First I did a yum remove varnish. However, once version 3 is on your server, yum install varnish will reinstall it. On a Centos server I had to go to /etc/yum-repos.d and delete the Varnish repository. Then reinstall the earlier versions of the varnish libraries. The single noarch bundle (find packages here) did not work for me on my 64 bit Centos el5 server.

If you are doing a fresh install, note that installation is tricker on 64 bit OS because it is all too easy to get the wrong versions of the various libraries required by Varnish. Be careful about to get the correct ones.

Then I had to install the old rpms:
rpm –nosignature -i http://repo.varnish-cache.org/redhat/varnish-2.1/el5/x86_64/varnish-libs-devel-2.1.5-1.x86_64.rpm
rpm –nosignature -i http://repo.varnish-cache.org/redhat/varnish-2.1/el5/x86_64/varnish-libs-2.1.5-1.x86_64.rpm
rpm –nosignature -i http://repo.varnish-cache.org/redhat/varnish-2.1/el5/x86_64/varnish-2.1.5-1.x86_64.rpm
(Go to the same URL for the relevant debug and docs libraries.)

Now yum install varnish. Find varnishd (for me in /usr/sbin) and do varnishd -V to check you have version 2, not version 3! The config file (for me at /etc/sysconfig) is overwritten by every upgrade or downgrade, so you need to edit it for the location of your VCL file, and to put Varnish on port 80. Should be good to go!

If you have not used Varnish before, once you have proved it will start from command line, of course you are likely to need a VCL file to configure it to work well with your installatio. Probably you need something other than the default.vcl supplied. But that is another article. If you are on Varnish 2 you should have no problem in finding something on the net. For Drupal, Pressflow’s example is a good starting point.

On this site, I did not succeed in getting anonymous comments working on cached pages with Varnish. Caching just the front page is of course possible (though you have to strip cookies under vcl_fetch, otherwise you get a ‘hitpass’ from the cache, rather than an hit). But, with the site behind Cloudflare, I found a cached front page was loading slower than an uncached page. If anyone can explain that, please let me konw!

BTW if you are installing for the first time on cPanel, check out UNIXy. I have not used them but it looks good. There are some additional complications with installing on cPanel, but they are not great. Still, given the time it takes to get the hang of the new software, the price of the cPanel plugin is probably worth it.

Web tech note–Adding third nameserver with Cloudflare

Aside

Reply

When you use Cloudflare you must use their nameservers. They provide two. If their nameservers are down your website goes down. Therefore it is tempting to add a third and fourth nameserver. However, if you add other nameservesr (perhaps your original ones) as third and fourth nameservers at you registrar, these will be used some of the time, since they are picked randomly. Therefore some clients will be sent to your server directly. My solution is to add a third nameserver but not a foruth, creating some redundancy, and accepting that a third of the traffic will not go via Cloudflare.

Web tech note–Cloudflare review

Posted on by
Reply

Cloudflare is a free or cheap CDN. This review relates to the free version. There are plenty of other explanations of how this works, so I will not repeat them here, beyond saying that it is a network of servers around the world which should serve static content, such as images and css files, from a server local to the client. Cloudflare also increases security by challenging automated attempts to access the site from spam and hacking bots.

My experiences with Cloudflare.

There is a free version, and a ‘Pro’ version which provides prefetching of web pages it thinks the client may want, and enhanced security. There is a saying that if it sounds too good to be true, it probably is. However, during the dot com bubble there were many good free services. Whether or not Cloudflare will be able to continue this business model, who knows. For now it seems excellent. I have not been with Cloudflare long enough to comment on their Analytics.

Downsides

I have only had an account for a couple of days and comment on this. The additional layer of caching is extremely irritating when you are constantly editing the site, notwithstanding that Cloudflare has a development mode.

Cutting spam

My website is fairly new and the bots have not found it yet. I do not yet know whether I need anything over and above the spam protection already installed. Other reviewers report positively on this aspect of Cloudflare, which has to be worth having, provided there are no false positives, challenging genuine visitors. I have not been using Cloudflare long enough to know, and of course one rarely gets to hear of a genuine visitor turned away.

Cloudflare adds to, but does not replace, tuning the server and site for speed

I have done a lot of work to get this website working fast. There is no substitute for tuning the server and website by hand for your needs. Cloudflare is only serving static content, so the speed of generation of your page, by WordPress or Drupal or whatever CMS you are using, is still down to your own server. If you are going to tune that server to be fast, and if you are using Cloudflare, you need to think through the additional implications for how to set up the server, rather than just switch on Cloudflare and forget it. Having said that, if your approach is to make the most of the server or hosting account you have, without a lot of tinkering to improve performance, it is safe to just switch Cloudflare on, and you can reasonably expect an improvement in performance. That is especially true if you are on a low grade hosting account or an overworked server.

Cloudflare support

The emails back from staff are friendly and helpful. When I sent a request at the beginning of the weekend, I had to wait until Monday for a reply. I cannot complain about that with a free service! Even with their paid service, considering its low price, this would be acceptable IMO.

Speed tests on Cloudflare

Impressionistic speed tests, with and without Cloudflare, from same location and time of day, two days running: very hard to say whether Cloudflare improves speed, but on the whole page load times using Cloudflare have been a positive experience.

Timing page load with Firebug, with and without Cloudflare, from same location and time of day: hard to judge because the browser cache may contribute to load times, and various other factors, especially with multi-layer caching on the server.

After several page views I was getting these average times (averages of load times to view seven or eight different pages on the site):

page size first page lookup browser refresh
with
Cloudflare: 8.34m 1.63s (onload 2.73s) 2.35s (onload 4.4s)
without
Cloudflare: 6.1mb 1.32s (onload 2.48s) 1.65s (onload 4.02s)

The first page lookup might have been pulling some files from the browser cache, so I take the figures for refresh times as more reliable. On this basis, Cloudflare wins.

Webpagetest.com results, testing from Paris, and Dulles TX. I ran about 15 of these tests. Results are variable, of course.

The results without Cloudflare, for the dedicated server, running Varnish (but a poor hit rate for WordPress, a problem I am working on!), and with W3 Total Cache page cache enabled, gave speeds in the range of 2.3s-3.7s (excluding a few slow ‘outliers’). The slowest page loads I saw with Cloudflare were 2.3s. If they are claiming an average improvement of performance of 30%, I would not argue.

Takeaway conclusions from review of use of Cloudflare on Classics Blog

Cloudflare is worth using because it gives some speed advantage. It adds to rather than replaces the need to tune your website and server. It is not only for sites on slow servers, either (though keeping bots out and saving bandwidth is more important if you are underpowered). The claimed security advantage and the analytics are probably worth having but it is too soon for me judge. Cloudflare support is good considering the price. Downtime: who knows? So far, so good.

Web tech note–configuring Varnish 3 to cache with Drupal and WordPress

Posted on by
Reply

I am a fan of Varnish caching reverse proxy. It is running on the servier where this blog is hosted. In theory it is not very relevant for this site because I am using Cloudflare, a free CDN which claims to cache the website. I am not sure how how long they keep the cache, but every request I make for a page from a logged-out browser is in fact hitting my server, so server speed is important.

WordPress is anyway fast and offers sophisticated caching with the W3 Total Cache plugin (or various other plugins which are almost as effective and simpler to use), but nothing beats Varnish serving pages from the Varnish cache for speed, particulary if you have a busy site (as I hope Classics Blog will be: yes, a server technology which should stay reasonably functional for 1,000,000 page requests per day is a little excessive at present!).

My server has several Drupal sites on it, in particular an online shop I built for a bookseller friend, P J Hilton, so Varnish has to be configured to work with Drupal. Every time you upgrade Varnish, they seem to change the syntax of the configuration language, so you have to amend the config file, which is a pain. Anyway, now I am using the new Varnish 3, and have finally got it to work, using the VCL config file which can be downloaded here. The file is called drupal_trial because writing it has been a trial (I regret upgrading from Varnish 2, which was working fine). And because it is a work in progress, I am trying things out.

What about WordPress? WordPress seems to set a PHPSESSID cookie for non-logged-in users, and other cookies. In any event, the Drupal 6 and Drupal 7 sites were being cached nicely with this Varnish config, but I was struggling to get clssicsbog.net (on WordPress) to cache.

The quick and dirty solution was to strip all cookies for non-logged-in users on a per-URL basis (i.e. for http://classcsblog.net only).

Pop this into a Varnish config file basically written for Drupal:

# remove cookies for my WordPress site, normalize namespace first
if (req.http.host ~ “(?i)^(www.)?classcsblog.net”) {
set req.http.host = “classicsblog.net”;
}
if (req.http.host == “classicsblog.net”) {
if (!(req.url ~ “wp-(login|admin)”)) {
remove req.http.Cookie;
}
}

It works!