2011/1/20 Alvaro Lopez Ortega <[email protected]>
> On 20/01/2011, at 05:13, Jędrzej Nowak wrote:
>
> > For me the option Alvaro idea is OK, but the consistency as Diego says
> > is important too... so maybe it's even better to remove the cpu count
> > and just leave the cores count ? ( exactly as Diego says )
> > And there is still 3rd option "2,4 GHz, UNK Logical Processors, 2
> > Cores" which is bad for me...
>
> Even though I do agree with keeping the interface as consistent as possible
> across all the different platforms, I think we ought to evaluate what is
> more important: the consistency along every single platform, or to remove
> features from users who could actually have them.
>
> In this case we are talking about a quite superfluous feature without which
> we could live. However, there will be occasions on which the common lowest
> multiple of supported technologies may leave us without any available
> option.
>
> There are two kind of situations. First, where a widespread technology is
> missing form a certain platform, like the case we are discussing about. The
> second is when there is an interesting technology available on a single
> platform: think of RBAC on Solaris or HTTP deferred accept on BSD. I will
> stick with the former case, since the technologies on the second group can
> be considered nice-to-have, and thus no really a priority.
>
> IMO, the right thing to do is to try keep as many people as happy as
> possible. Basically, to try to maximize the positive user experience in the
> real World. That means that we ought to take into account that there are
> many more people using Cherokee on Linux and MacOS X than on BSD, and
> therefore the 'damage' of losing functionality on those environments would
> be multiplied a 'higher impact' factor.
>
> In this specific case, I do not think that keeping the consistency of a
> tiny string across the complete set of supported platform would be worth the
> lose of functionality on the most used ones, actually.
>
> You know, this is all about providing the best possible experience for as
> many people as possible.. and even if sometimes it is not trivial to
> evaluate what the best option is, we must keep the target in mind.
>
Agreed.
Earlier in this thread I mentioned I was discussing on this with the guy who
reported the issue
on FBSD 8.x (Anton Lazarov). He contributed some interesting ideas I think
worth considering:
1) Poll the actual CPU frequency in systems where frequency scaling is
available and get
displayed as a gauge for each CPU core.
2) Get the 'active' memory usage I mentioned earlier, which is BSD specific.
3) Be able to see the actual amount of memory used by Cherokee worker
processes.
What do you guys think about writing a small C program to acquire all the
info we want to
get displayed in the admin interface, instead of relying on vmstat, sysctl,
/proc, etc?
I mean, a common program for all platforms but putting all the logic we have
now
SystemStats.py in there. This vmstat-like imaginary program would dump all
the platform specific
info in a generic way, it could even be in JSON or YAML.. Call it
"cherokee_sysinfo" :-)
But I must insist, all of these are just ideas.
cheers,
diego
> Cheers!
>
>
> PS: BTW, please, do not CC the announcement mailing list on these
> discussions. :)
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
