On Aug 26, 5:55 am, Alvaro Lopez Ortega <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > FWIW, if would do much better to Cherokee's credibility, presuming you
> > speak for its development team, if you present proper informed
> > analysis rather than conjecture and FUD.
>
> Graham,
>
> First, I am glad you are interested on Cherokee and the decisions we are
> making. In fact, I could not think of anybody else who could comment on
> this better than you (as mod_wsgi author).
>
> So, first of all, thanks for the long Apache internals tutorial. It has
> been enlightening (seriously, even if it is a program I do not fancy
> very much, there were a couple of interesting points I did not know).
>
> However, there are a number of things you said I can not agree with.
> The first and most important one, is the design flaw. Let's try to
> forget about Apache for a second. Let's forget about its performance
> issues (a few of them might be Layer-8 issues as you pointed) and its
> ancient NCSA inheritance. Let's focus for a second on information
> systems design from a high level point of view. From that perspective,
> keeping the application logic, data and representation independent from
> each other (MVC-like) is a good idea; I do not think there is much to
> discuss about it. The very same principle applies to this case, keeping
> the transport layer (the web server) and the application logic
> independent IS a good idea as well, regardless of any concrete
> implementation.
>
> There is a bunch of examples and similes that support this affirmation.
> Well known and accepted programming paradigms, the Unix way of working:
> applications with a single purpose communicating with each other (never
> embedding), or even the current web technology where people keep their
> data, formating (css) and application logic independent for the shake of
> maintainability.
>
> Besides that, there was another thing you wrote that caught my
> attention. As we all know, size matters (in this world, big is bad
> though).  You said that the Python interpreter is not that big, and you
> were partially right, although you missed the Principle of relativity.
>
> Putting it in context will change your perception:
>
> --------------
> $ ps -eo rss,comm | grep python
>   3620 python

I'm confused here. This is my Fedora 8 desktop:

$ ps -eo rss,comm | grep python
17460 python

Now if you change the ps arguments to:

$ ps -eO rss,comm | grep python
 2439  8660 yum-updatesd    S ?        00:00:00 /usr/bin/python -tt /
usr/sbin/yum-updatesd
 2824 19084 puplet          S ?        00:00:00 /usr/bin/python -tt /
usr/bin/puplet
 2833 17460 python          S ?        00:00:00 python /usr/share/
system-config-printer/applet.py
13140   692 grep            S pts/8    00:00:00 grep python

That memory usage you show is not used by the interpreter alone but
mainly by the application, in this case yum-updatesd, puplet and
applet. Isn't it?

Regards, Clodoaldo Pinto Neto

>
> $ ps -eo rss,comm | grep cherokee
>   1856 cherokee
>
> $ ps -eo rss,comm | grep apache2
>   2068 apache2
>   2216 apache2
>   2220 apache2
> --------------
>
>      0      1Mb     2Mb     3Mb     4Mb     5Mb     6Mb     7Mb
>      |       |       |       |       |       |       |       |
> Che |=============>                                         |
> Py  |===========================>                           |
> Apa |===================================================>   |
>
> For the record: Python was a completely empty interpreter with no
> imported modules at all. Cherokee was using the default set up for
> serving static content, and Apache was configured with a minimum number
> of modules (even logging was commented out).
>
> So, despite what you suggest, if a bare minimum interpreter is twice as
> big as the web server, I wouldn't personally call it "small". IMO Python
> rocks anyway, but calling it small may be too much.
>
> Anyway! Let's put the swords down.
>
> Graham, thank you very much for sharing your point of view with us. I am
>   sure that even if we have different technical approaches the
> discussion has been useful for many people.
>
> Hopefully someday you will join the project instead of marking my
> technical argumentation as FUD. In fact, what about trying to prove me
> wrong by writing handler_wscgi? Independently of the result, it'd lot of
> fun for both of us. ;-)
>
> Cheers!
> _______________________________________________
> Cherokee mailing list
> [EMAIL PROTECTED]://lists.octality.com/listinfo/cherokee
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee

Reply via email to