Since 2bits moved into using VPS (Virtual Private Servers) when Xen became available we did not have to directly use other technologies, such as Virtuozzo, OpenVZ (free version of Virtuozzo), or the older User Mode Linux.

However, two recent cases proved what we have suspected for a long time: that indeed Xen is superior to competing technologies when it comes to performance.

In one case, a client contacted us for tuning a slow system. The system gets some 75,000 page views per day on weekdays, and page generation times were 2 seconds or more, and was running on a Virtuozzo host.

2bits cloned the site on a test machine ran timing benchmarks, and found that it peformed faster on the test machine. Then we cut off the external traffic from the live machine using Apache LIMIT directives, and found that page generation times have not improved. Our recommendation to the client was to move to another host. They chose to go for a dedicated server, and that solved their problems.

In a second case, someone posted a request in the forums, where he was getting page generation times of 2+ seconds, while the query components were only 700-800 ms. Upon checking the output of phpinfo, it was apparent that they used OpenVZ. The user was trusting enough to send over a copy of the site's database and files, and we installed it on a Xen VPS.

The results were page execution time of 300 to 600 ms on Xen, as opposed to 2000+ on OpenVZ.

So, the advice is: for Drupal hosting best performance: use Xen if you want a VPS. Avoid Virtuozzo and OpenVZ.


Over the past few years, we have seen more and more clients who complain about poor performance and they ended up being on Virtuozzo. A common theme was the vzfs file system, which virtualizes the host's file system and shares it across the guest instances. This saves a lot of disk space, but from what we have seen, access to the disk is slow. Therefore, database queries are slow, and even serving cached HTML pages from boost is slow. If you are using Virtuozzo, and your site is slow, check to see if you have any of these signs.


Sun, 2007/07/01 - 23:33

I moved to linux-vserver. These servers are for one organization on dedicated servers. Not vps for rent to others. So not really like the situation in your post.

It is a chroot environment more like bsd jails. For my usage having the same kernel is not an issue. There is good support in Ubuntu and debian too.


Sun, 2007/07/01 - 23:40

They all work from a functionality point of view, whether it is OpenVZ/Virtuozzo, Xen, UML, or Linux Vserver.

My point was performance. Xen is far superior over OpenVZ. How does Linux Vserver fare in this regard in your case?
2bits -- Drupal and Backdrop CMS consulting

Mon, 2007/07/02 - 12:02

I was moving from self-hosted user-mode-linux and a couple of rented vps accounts on uml too. There was a little performance lag on them but mostly a stability problem on the ones I hosted on our dedicated servers. UML development had slowed and seemed to have been leapfrogged by these others.

I did not benchmark agains Xen but part of the decision making process was because the Linux-Vserver architecture could have performance advantages. It runs only one kernel for all virtual servers. The files in each virtual server are not in some COW like image so there isn't a slowdown there either.

I'm going to try Virtualbox on my development desktop to see how it works.

good subject again Khalid, thanks.


Sun, 2009/04/12 - 12:28

I'm far from an expert on virtualization technologies, but one Xen advantage over Virtuozzo (and maybe OpenVZ) is that you have /sys/kernel and all of the other directories that you would expect to see on under /sys on Xen. On Virtuozzo you don't see /sys/kernel and some of the others. I this has to do with how Virtuozzo shares a kernel between multiple containers on the host machine.

A problem that I've run into is that standard Ubuntu init scripts will fail because their tests for /sys/kernel fail. This happens with the HAL init script. You can start HAL interactively and therefore you can probably script a work around and run it on boot, but a can of worms is probably opening...

Mon, 2007/07/09 - 20:16

I have to back up Khalid here. We are former SW-Soft Gold partners, and were involved with OpenVZ from as far back as having made the suggestion to them to not call it OpenVirtuozzo due to brand confusion. ;-)

We have a massive cluster (several racks full) of XEN now running Drupal-based applications, and have found that in benchmarks, XEN and even VMWare bench far more reliably than OpenVZ and Virtuozzo.

The performance question is secondary to the fact that we can get consistent results using VMWare and XEN (we use XEN now almost exclusively, VMWare only for very large clients or those with a specific requirement).

It's the consistency that matters, because what you want to avoid is a couple of higher performance sites on a box crushing your performance when they get busy - that's something you don't get with "soft virtualization" systems like Virtuozzo, OpenVZ, or, sadly, even LVS (though proper architecture more than makes up for this with LVS). The only real sore point with Xen is the same point with any virtualization system - i/o constraint.

This isn't really a problem until you start running intensive database-driven applications, which includes Drupal. Then you start getting into the joy of "which system-tuned variable gets crushed first" with soft virtualization systems.

This isn't to say it can't be done, but default settings won't do it, and it's a LOT harder than just grabbing yourself a sliced up "hard virtualization" style box (XEN, VMWare, etc).

As usual Khalid, nice comments.

My 2c.

Jonathan Lambert
Principal & CEO

WorkHabit, Inc.

Tue, 2009/08/25 - 04:14

agree with you. I use vservers on my productive servers for some months, they now eat less system resouce compared to xen. Additionally...
1, as for my exp.,vserver is much easier to manage.
2, openvz is nearly the same as vserver, there's no absolute difference.

Mon, 2007/07/16 - 21:15

We run some OpenVZ VPSs and find them very fast (well, pretty much as fast as the raw hardware...if you get better than that something is wrong!). Most things I read seem to indicate that OpenVZ has a much lower overhead, and most better resource management when under pressure (especially because of the two-level scheduler). While your results are interesting, they do seem a bit anecdotal to me :)

For example, here is part of the conclusion from the HP Xen vs. OpenVZ study.

  • For all the configurations and workloads we have tested, Xen incurs higher virtualization overhead than OpenVZ does, resulting in larger difference in application performance when compared to the base Linux case.
  • Performance degradation in Xen increases as application workloads increase. The average response time can go up by over 600% in the single-node case, and between 115% and 600% in the two-node case depending on the number of applications.
  • For all the cases tested, the virtualization overhead observed in OpenVZ is limited, and can be neglected in many scenarios.
  • For all configurations, the Web tier CPU consumptionfor Xen is roughly twice that of the base system or OpenVZ. CPU consumption of all systems and all containers goes up linearly as the workload increases. The slope of increase in the case of Xen is higher than in OpenVZ and the base cases.
  • Mon, 2007/07/16 - 21:25

    Out of interest - I noticed that you said that in the second case, you installed the problem site on a Xen VPS. However it was not clear that the Xen and OpenVZ site instances were hosted and benchmarked on the same machine. If not, then I don't think you can really compare the results, since even the best resource scheduling can't make Xen on a dedicated unloaded server compete with OpenVZ on an underspecified shared server that happens to host a porn network ;)


    Is your Drupal or Backdrop CMS site slow?
    Is it suffering from server resources shortages?
    Is it experiencing outages?
    Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting