[Cherokee] Benchmarks of cherokee vs nginx

Tony Zakula tonyzakula at gmail.com
Tue May 24 18:52:41 MSD 2011

And you certainly cannot report on memory consumption relying on
OpenVZ fake memory numbers.

On Tue, May 24, 2011 at 9:50 AM, Tony Zakula <tonyzakula at gmail.com> wrote:
> Was there any info on how OpenVZ was setup or how many other
> containers were running on the machine, Do we know what the load was
> on the machine at each stage of the tests?  We really do not know
> anything.  The web servers were not even setup the same.  The hosting
> outfit could see a system spike and automatically kick in a limit that
> we do not know about. I do that all the time. That is a common
> practice.  If you do not control the system, you cannot do a valid
> benchmark.
> On Tue, May 24, 2011 at 9:39 AM, Cliff Wells <cliff at develix.com> wrote:
>> On Tue, 2011-05-24 at 09:25 -0500, Tony Zakula wrote:
>>> I am not complaining about OpenVZ.  I deploy servers on a regular
>>> basis using OpenVZ.  I also deploy using KVM, and others.  There is a
>>> massive difference between OpenVZ and KVM in implementation, system
>>> stability, etc.  They are entirely different animals.  You cannot
>>> discount the hypervisor.  The hypervisor can make or break your
>>> application depending on how you're application is structured.  For
>>> instance, Java apps run great on KVM hypervisors, but really poor if
>>> at all on OpenVZ unless you tune the OpenVZ instance to meet your Java
>>> apps needs.  The reason for that is the way Java handles memory.
>>> Threads is another big issue hypervisors. To say that the hypervisor
>>> has no effect on application performance is not accurate at all.
>> So are you suggesting no benchmark is ever valid unless it is run on
>> every hypervisor available as well as on the bare metal?  Clearly every
>> benchmark has defined parameters, and in this case OpenVZ was one of
>> those parameters.
>> So long as the benchmark is defined as "Nginx vs Cherokee under OpenVZ"
>> then it's a perfectly valid benchmark.
>> Cliff

More information about the nginx mailing list