On 24 Jul 2008, at 20:21, Milo van der Linden wrote: > M. David Peterson wrote: >>> >>> //1//- Monitoring website behaviour might be useful (2 comments >>> including mine), but we prefer not to use Google (2 comments). >> >> Honestly, as far as the Cherokee project is concerned, tracking using >> behavior is a red herring. It's a distraction from what matters most: >> The number of active installations in use on the web.
Completely agree. +1. >> In other words, what should matter most is how many people are using >> Cherokee, not which pages they visit on http://cherokee-project.com >> on >> which day. That's not to suggest that understanding the >> behavior(s) of >> site visitors is a bad thing. It's just not as important as actively >> supporting and evangelizing the product. If people have a problem >> with >> the site, they'll either tell you or never come back again. And in >> my >> opinion the best way to ensure the former rather than the latter is >> to >> provide a proper and positive snapshot of community activity. >> Cherokee >> is an active web server project. But that's not immediately obvious >> when you visit the site. e.g. Benchmarks from 4 top level releases >> ago >> which provide nothing more than superficial benchmarks based on >> nothing >> but seemingly random numbers pulled from out of hat. No links. No >> "Here's the benchmark we used.". Nothing. > > I have a virtual machine ready with the latest svn cherokee, lighttpd > and apache to rerun the benchmarks. I am only waiting for the 0.8.0 to > reach stable. Then I hope the new benchmarks will find their way to > the > website. I have automated the installation script for > cherokee/apache/lighttpd. It can be re-run with every new release ;-) > Hope that partially answers one of the questions. That kind of environment would be pretty useful for the developer team as well. In fact, it is not the first time we talk about setting up an automatic benchmarking environment (imagine something like Tinderbox but focused on performance). Basically, it would raise an alarm whenever a commit has a negative impact on the server performance. I don't think it is something we need right away, but it's definitely a nice-to-have that we should keep under the radar. By now, our main efforts ought to be focussed on improving the project marketing, finishing Cherokee 0.8.0, and last but not least, continue writing a decent documentation. >>> Thanks again and I know my homework for now ;-) >> >> Let me just add that I am definitely in the mindset that if the >> Cherokee >> project can find ways to both document and promote themselves >> better, I >> am definitely interested in both using it and promoting it far and >> wide. I currently have Lawrence Lessig's media server running on >> Cherokee > http://media.lessig.org/ <. There are several of both his >> sites as well as several other sites I'd like to move to Cherokee as >> time allows. But it's really hard to convince people like Professor >> Lessig "the reason we need to use this web server is because of ..." >> when the only "..."'s I have available to me are ambigious benchmarks >> and hearsay about how much Cherokee *rocks* the casbah. >> >> Sincerely, >> A Cherokee Fan Thanks a million David, your words are very encouraging! -- Greetings, alo. http://www.alobbs.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
