2

I use NGINX on my server as WWW server.

Now, I've seen Cherokee being used on some pages, such as university websites.

Is it advisable to use it, when I have dynamic content (some of it in PHP, some of it in Perl, some other in Lua, and some in Python)?

How does Cherokee tackle the C10K problem?

My server is rather slow and low on specs (Intel Atom, etc) so please don't advice Apache; also, I've used Lighttpd, and didn't like it. NGINX was the best I used so far, but maybe Cherokee is a better alternative?

polemon
  • 565
  • 2
  • 8
  • 21
  • 1
    what reason exactly is making you want to change, what are the specs of the machine that nginx is running on, what kind of load will it be handling etc – seanl Nov 30 '10 at 11:09
  • 1GB RAM and 1.6GHz Intel Atom CPU. It's not handling a lot of load, but there's other things running on the server as well, so I'd like the web server to be as little resource demanding as possible. This, however, should be the universal approach, IMO... – polemon Nov 30 '10 at 21:48

3 Answers3

1

I strongly recommend you to give it a try. We have been using it for a while now, and I must say the experience has been fantastic.

Besides being light and highly scalable, it's shipped with a graphical configuration interface that allows to tweak every single parameter of the web server.

All in all, it's at least as fast as Nginx (faster according to some benchmarks), it is much easier to configure and to administer (it build usage graphs representing connections, timeout and traffic), and it is maintained by a very active community (with public source code repository, bug tracker, etc).

Give it a try, you'll like it for sure.

Clay Peng
  • 11
  • 1
1

I use cherokee to host a django app using WSGI. The wizard to'deploy' an app is very useful, as is the temporary admin mode/server.

You should try and do some benchmarking. For me its stable.

PieterB
  • 91
  • 1
  • 6
-1

@polemon,

An erratic curve is the sign of the Web server program figthing to cope with the load.

As concurrency grows, most Web server software programs will enter this kind of pattern (until the OS kernel itself is the cause of this problem for all user-mode applications).

The pics (high and lows) are due to the inability of the program to respond in a timely fashion. As a result, some threads are taking longer because they are blocking (starving from CPU resources) while others are 'released' by taking almost all the CPU resources.

The only way to prevent this from happening is to write lean code that takes as little time as possible to execute (so concurrency is not so painful).

Hope things are easier to understand now.

Michi
  • 1