Hi Eduardo,

 

First of all, no problem with the delay to respond as long as you just send
me a short message such as “Hi, I’m too busy right now, but I’ll come back
to you within a week or so.” That’s fair.

 

Now, I truly do appreciate your work and your community effort to make
Monkey shine.

 

However, even if it’s already a 10 year development effort, there are still
a bunch of works to do (especially with your FASTcgi interface) to make it a
winner and I’m sure you’ll succeed.

 

Now, I’m very sorry but please I truly hope you won’t be hurt by my words
about your “wr” tool that’s (in a very polite way to say it) nothing but a
kid’s tool !

 

Further, it’s an “ “ unfair solution for certain web servers since it isn’t
able to start the maximum number of threads or processes that such or such
other web server is able to handle using the basic weighttp tool you tried o
“ “ wrap  to automatically uses the maximum performance of any web server,
accordingly to the hardware used to run these web servers (i.e. the unfair
comparative Monkey Vs. Gwan published on your web site where your “wr” tool
started a) an old release of Gwan and b) with only 2 threads – I tried your
“wr” stuff with Apache2, Lighyttpd and Nginx and it’s the same thing.) !

 

So please, don’t pretend to make such a “ “ fair wrapper purportedly based
on the Trustleap “ “ ab.c free and public development code!

 

Please… and we’ll stay friends since I’m sure you don’t want that I publicly
comment your “ “ wr  code.

 

That’s why I made my own specific wrapper using both weighttp and a bunch of
code lines from the last “ab.c” developed by the G-WAN development team that
is now able:

 

- to measure a real growing load of concurrent clients requesting small or
large amount of simultaneous requests of small or large static and dynamic
contents,

 

- to collect and display (both on screen and in result formatted files to be
directly be usable to draw charts) a lot of system information such as used
resources, execution timings, errors and so on in order to:

 

a) be reproduced by anyone on any system,

 

b)  tracks “ “ cheaters publishing false or “ “ oriented results!

 

Of course, the source code of my tool as well as the OSes system settings
will be available within my article and will be freely downloadable from a
web site.

 

As I said to you earlier several times, I don’t want to be unfair with any
contender!

 

The results will be the results, with a fair analysis of the “ “ pros and “
“ cons of each product.

 

And even more, I will of course publish the different basic settings used
from “ “ scratch for each web server, but also before to publish them, I
will (as I’ve done with you) request to each competitor to give me its “
“advice to get the best of the bread of my 2 hardware references (a – an AMD
based server and b – a similar Intel based server) that are commonly used
today by ISPs and ISVs.

 

Furthermore, the comparative tests will be made on these 2 reference based
systems with ALL of the following OSes:

 

- the “ “ pure ArchLinux rowing 64 bit,

 

- CentOS (final release) 64 bit,

 

- Debian 7 (Wheezy) 64 bit,

 

- Fedora 18 (Schrödinger’Cat) 64 bit,

 

- LinuxMint 15 (Olivia) 64 Bit,

 

- The very rapidly growing Manjaro 64 bit,

 

- Red Hat Enterprise Linux 6.4 (Santiago) 64 bit,

 

- Ubuntu 10.04.4 LTS 64 bit (because the facts is it’s still the fastest of
all the Ubuntu “ “ collection yet – sorry to Canonical about its wandering
with “ “ Unity stuff…but numbers are numbers),

 

- And Ubuntu 13.04 64 Bit (the last one Canonical flagship – just to play
with it…).

 

As I said to you earlier, I’m not affiliated with any contender (OS or Web
Server providers)! 

 

I’m only “ “ paid by my publisher editor and “ “ our goal is to clean up a
little bit this “ “ dark arena (where anyone is using cheating measures and
fake arguments to pretend to be the “ “ best).

 

So, the contender list of my article (not by preference but only by
alphabetical order) is:

 

- Apache2

- Cherokee

- Gwan

- IIS (the only one tested with the MSFT Windows 7 64 bit OS)

- Lighttpd

- Monkey

- Nginx

- Tomcat

- Varnish

- Zend Server

 

Then… you now know who are all the Monkey’s contenders… and trust me, the “
“ race will be tough!

 

BTW, to make you feel comfortable, you already got a very high point with
your responsiveness to support your user folks… (like me)!

 

Hope we’ll nicely talk again soon.

 

Cheers and once again, thank you for your response.

Null4ever… !

 

PS: BTW, please don’t “ “ rely too much on my writer “ “ pseudo. I’m not
that such a “ “ dumb Linux beginner my pseudo is used for! LoL. J

 

 

From: Eduardo Silva [mailto:[email protected]] 
Sent: Friday, September 27, 2013 9:00 PM
To: Null4Ever
Cc: Monkey; Duda
Subject: Re: Monkey by design limit !

 

Hi, 

 

Sorry for the late reply, answers between lines:

 

On Fri, Sep 27, 2013 at 12:48 PM, Null4Ever < <mailto:[email protected]>
[email protected]> wrote:

Hi all,

 I already requested some explanations about how to make Monkey able to
respond to more than 504 simultaneous clients connections (63 clients per
core x 8 cores => that is the limit I get on my machine with an AMD 8150 FX
8 Cores @ 4.2 GHz, with 32 Gb of RAM and 2 SSD Crucial 240 Gb.) but never
got any answer!

The first thing is to define the number of workers that you want to have. In
the monkey.conf configuration file you can set Workers key to some value > 0
(value 'zero' means spawn one worker per CPU core).

 

Monkey will be able to handle 1/2 of file descriptors limits imposed by the
system for the process, e.g: if you check your limits with "ulimit -a", you
will see something like:

 

$ ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 62698

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 62698

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

 

the "open files" line means the number of open file descriptors that the
program can have open, so if it says 1024, Monkey will allow 512, because it
reserve 50% of them for any later usage for plugins or any other related
task.

 

In order to increase the capacity you have to increate the open files limit,
e.g:

 

$ ulimit -n 2048

 

now you will see the number of open files increased to 2048, depending of
your Linux distro a higher number would require root privileges to perform
that change.

I’m writing an article comparing the raw performances of several Web Servers
with multiple detailed benchmarks using both small and medium HTML fixed
size files as well as small and large dynamic contents requests and it would
be a shame to see Monkey excluded from the competition since it always stops
to respond when the 504 simultaneous clients connections limit is reached
but that all the 5 other web servers sustain (with of course different
results).

So, is anyone able to tell me where in the code of Monkey I can change this
current per core limit of 63 simultaneous clients, let’s say to try a
minimum of 128 up to a maximum of 256 (that are values easily supported by
some of the Monkey’s competitors)?

already explained above.

If not, the benchmark graphs will show Monkey at the last place, even after
the good "old dog" Apache2!

Is this what you want to read in a large specialized computer revue that
would ruin this community efforts?

just make sure to use the proper tool for benchmark, as we talked in private
email we use the 'wr' tool which is a wrapper over weighttp:

 

 <https://github.com/edsiper/wr> https://github.com/edsiper/wr

 

once you get the source code just type 'make', then to run the tool you need
to know the following:

 

 1) Web Server process ID, on this case Monkey PID

 2) Number of initial concurrent client connections

 3) Number of maximum concurrent client connections

 4) Number of requests per client connection

 5) Step client connections

 

we suggest:

 

./wr -r 500000 -c 100 -l 500 -s 10 -p MONKEY_PID   <http://host:port/file>
http://host:port/file...

 

if is there anything extra you need help with let us know, 

 

best

 

-- 

Eduardo Silva
 <http://edsiper.linuxchile.cl> http://edsiper.linuxchile.cl
 <http://monkey-project.com> http://monkey-project.com

_______________________________________________
Monkey mailing list
[email protected]
http://lists.monkey-project.com/listinfo/monkey

Reply via email to