[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