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@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
>
>


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx