A month and a half ago I blogged about CloudFlare – a Content Delivery Network with security concerns and simple users in mind. CloudFlare is flexible for webmasters and they make it easy for us to take advantage of all the benefits they offer. I have moved several of my sites to CloudFlare and I am pretty happy with the service they provide. One of the things that I didn’t do at the time (or every since) though is a review or research for some alternatives. I mean, of course, we all know about Akamai and that big guns use it. We also know that Akamai is one of the most expensive services on the Web. But who else is out there?
Today I received an email from Incapsula. In essence, they offer a service which is similar to CloudFlare. They do caching, global delivery, and security. They do also offer a free plan for small, personal websites. They also have a few packages of varying prices and features.
As I mentioned earlier, I do run all of my important sites now through CloudFlare. And I don’t feel like moving to Incapsula just yet. However, I do want to try them out. I have a couple of new projects coming up, and I think I will use Incapsula for them just to see all the features they are offering and to compare with other alternatives out there. I’d be interested to hear the reviews, if you’ve tried the service. Especially, how they compare to the others and if they offer anything cool that nobody else does.
As a side note, website performance is becoming more and more important – with increased competition, impatient users and more weight to search results metrics in Google. Also, web application security is becoming increasing complex – it takes so much time and effort even for trained technical people such as myself, that I can’t imagine how huge of a task it is for “normal” people to maintain common sense security levels for their websites. It’s nice to see that there are more and more services and applications that take care of all the infrastructure problems, leaving more time to do the cool stuff – blogging, sharing, communicating, etc.
P.S.: Reading about Six Great Human and Computer Collaborations will expose you to new technology developments.
I’ve heard a few mentions of CloudFlare before, but I never gave it much attention. Today, after reading this blog post, I decided to give it a try.
What’s more, that 30-40% increase that people used to see is now in the range of at least 50-60% as the team continues to find ways to make CloudFlare faster, while still offering security at the forefront.
What is CloudFlare, you ask? As per their own website:
CloudFlare protects and accelerates any website online. Once your website is a part of the CloudFlare community, its web traffic is routed through our intelligent global network. We automatically optimize the delivery of your web pages so your visitors get the fastest page load times and best performance. We also block threats and limit abusive bots and crawlers from wasting your bandwidth and server resources. The result: CloudFlare-powered websites see a significant improvement in performance and a decrease in spam and other attacks.
In simple terms: CloudFlare is very cheap (even free) content delivery network (CDN). It provides speed and security improvements, and it is extremely easy to configure. I know so, because I’ve already registered for the free account and configured this site to benefit from the service. Whether it actually lives up to all the hype – I don’t know yet, but I’ll see in the next few days. I suspect it does, since there are numerous positive reviews around the web. I will of course let you know. Especially if you remind me.
Stale cache is responsible for at least 40% of all heart attacks. At least for people working in the IT industry.
I came across an interesting tool – Which loads faster?, which allows you to load two web sites side-by-side and measure which one of those loads faster. If you reload the sites several times, you’ll also get the average statistics across all runs.
O’Reilly Radar runs the blog post comparing performance of several cloud services. While everyone should run their own tests and benchmarks before deciding which one is better, the article provides a nice summary. Here is the graph based on their results.
While investigating an unrelated issue on our backup server, I came across an interesting discussion about gzip vs. bzip2. I was surprised to read on how much slower bzip2 is. I even tested it on our server. And as expected, I saw the huge difference.
$ du -sh home
$ time tar czf test.tar.gz home
$ time tar cjf test.tar.bz2 home
$ ll test.tar*
-rw-r--r-- 1 leonid users 365987716 2010-06-29 13:08 test.tar.bz2
-rw-r--r-- 1 leonid users 390655750 2010-06-29 12:56 test.tar.gz
For such a small difference in size, the compression time difference is huge! Of course, I should play with more parameters, repeat the tests several times, and test the decompression time too. But the above test is still a good indication. Way too many scripts out there use the default parameters and substitute gzip with gzip2 without any testing. That’s obviously asking for trouble.
It’s been bugging me for a while now that advanced search is extremely slow in our RT3. I thought it was something related to the famous Perl bug, but apparently it wasn’t. Then I was I waiting for Fedora 10 to come out, so that we’d upgrade our RT3 installation to version 3.8. And that didn’t solve the problem either. Finally, we got bored and annoyed enough by this problem to actually do soemthing about it. The solution was, as often, just a Google search away. Here is the quote from this discussion:
Faulty rights on a specific queue caused the owner list to be quite long, which RT didn’t like. (By mistake someone had given the own ticket right on the queue to all unprivileged users)
I went through all the queues to check the rights, and there it was – a test queue had “Own Ticket” assigned to “Everyone”. Immediately, after remove this access levels things got back to normal.
After SugarCRM was deployed, we were experiencing some lock ups. Not frequent or dangerous, but annoying. About once a week or every ten days or so, SugarCRM would lock up and won’t answer any queries at all. Not even the login was possible. A brief investigation showed that somehow it was locking up the MySQL database – about 15 processes (using “show full processlist”) in Locked state, with no data being sent back or forth. All locked queries were rather complex, with several JOINs. The load on the system was somewhat high, since we have about a few dozen operators working on it at the same time.
A similarly brief Google search suggested (see here and here) and explained converting MySQL tables from MyISAM to InnoDB. A test has been performed and everything went OK. Our SugarCRM database is about 600 MBytes and it was converted from MyISAM to InnoDB in under 20 minutes. The best part is that it takes even less to convert back to MyISAM, in case you change your mind.
It’s been a few days now since we did the conversion and it looks OK. Also, the CRM itself feels a bit faster.
I noticed this ticket in WordPress Trac – Change enum to varchar and went in to see if there is any heated discussion.Â The issue is around field types used in SQL scheme for WordPress tables.Â Certain fields, such post status employed ENUM type with a set of allowed values.Â The proposed change in the ticket is to convert them to VARCHAR type.
Why the change?Â Well, VARCHAR is just a text field.Â Anyone can put pretty much any string into it.Â It has more flexibility for plugin developers and future changes – no need to tweak the SQL scheme.Â ENUM on the other hand works a little bit faster.
Side note: I also thought that ENUM provides some extra data validation, assuming the ENUM field is set to NOT NULL, but it turns out this is not the case.Â If you insert a record with a value which is not in the list, the NULL is used.Â
The change has been approved, the patch was attached, and the world will see it in the next WordPress release.Â Once again, it has been proven that human time is much more valuable than machine time.Â Making it easier for plugin developers to extend and change the system has more value than that of a few extra CPU cycles to lookup in strings instead of numbers.
I was just reminded about this small thing, which is so easy to forget – regular expressions that have markers of line start (^) and/or line end($) are so much faster than those regexps that don’t have these markers. The thing is that with line start/end marker regexp engine needs to make only one match/substution, whereas when there is no such markers, it has to repeat the match/substitution operation at every character of the string.
In practice, it’s unbelievable how much difference this can make. Especially when using complex regular expressions over large data sets.
P.S.: I understand that it is not always possible to use these markers, but I think that they can be used much more often than they are. Everywhere.