antirez
More active development
Hello,
because of time concerns in the past I was not able to test pull requests and merge them in a reasonable amount of time. Fortunately after asking @fcambus for help, he accepted, and that's the idea:
- For a pull request to be accepted, both I and @fcambus need to agree about the feature, in order to reduce bloat.
- After 2 weeks a given PR was opened, if one of the two still did not expressed his idea, the other is authorized to act unilaterally.
For contributions, please in general try to:
- Keep it simple.
- Add only things that are generally useful for most installations.
- Don't use Ruby magic.
- Always benchmark if page generation time regressed sensibly.
Lamer news point is that's simple and fast, and as a side effect it is also a good Redis programming example. Still we need it to evolve, but would be cool to keep this spirit. Thanks!
@antirez +1 for this issue, anyway I don't see any benchmark test, if you have already done some can you please include them?
@potomak I use the usual stuff like apache benchmark or other similar tools (there is another quite good available via homebrew, but I can't remember the name right now), to benchmark the home, latest, and the comment pages mostly, that is where most of the computational expansive operations are performed.
Probably we should add something in the README file about the setup to perform the benchmark, like the web server used, version of ruby and hiredis, what it a sane range of ops/sec you should see before modifying the code, and what is an acceptable lose for a significant feature added (for example, 5%).
No time to do that currently, but I think it's a really good idea...
I propose we use this thread to debate about new features / pull requests.
I've been going through issues and pull requests, and closed some issues which requested features which have been implemented since. There is still work to do though :) Actually a lot of pull requests contain some stuff related to deployment : Gemfile, config.ru, and stuff specific to hosting platforms. I moved one such issue here : https://github.com/antirez/lamernews/wiki/Deployment
Not sure what we should do about those issues. Maybe put hosting platforms instructions (Heroku and stuff) in the Wiki, and just include a config.ru file in the repository?
Lamer News is now Ruby 1.9.2+ compatible, I believe it will make life easier for potential new users / contributors.
On this topic, I think it would be a good idea to merge this commit, so everything would work out of the box with default configuration :
https://github.com/qrush/lamernews/commit/b40ac2961659abc194d13df0d19037fd4b3aa76e
Open questions :
- Validations for usernames : #134
Feature requests which should be discussed :
- Polls : #136
- Expose users via API : #140
A small hint how to do the benchmarks would be helpful for me too, e.g. in the context of the view layer extraction: https://github.com/antirez/lamernews/pull/143
Besides, I got the project running easily on Heroku and RedisToGo by using an URL for redis, like in this: https://github.com/antirez/lamernews/pull/144 - that is why I would prefer a benchmark that is independent of Apache :-)
For doing benchmarks, you can use ab (ApacheBench) as @antirez mentioned, a tool bundled with the Apache HTTP server but which can be used to benchmark any kind of HTTP server. If you are running OS X then it's already installed by default.
To benchmark the home (1000 requests with 10 concurrent connections) :
ab -c10 -n1000 http://127.0.0.1:4567/
Beware though, ab is single threaded and when testing high performance HTTP servers, it can be a bottleneck, especially when testing on localhost.
A better alternative is siege, which is available via homebrew.