4 ms·
Using Ruby on Rails and running on Mongrel, I assume?
by cmelbye 17y ago
Using Ruby on Rails and running on Mongrel, I assume?
- chasingsparks 17y agoHe posted sample python code for the rating system in a blog post. http://zedshaw.com/blog/2009-11-6.html http://zedshaw.com/blog/2009-11-6.html
- Scriptor 17y agoI think Zed's pretty much done with Rails. He said he'd only use it if absolutely necessary.
- garndt 17y agoChances are he used django for it. He has blog posts on his new found love for django and his ratings code is in python. According to the Lamson (his project) FAQ, Lamson was influenced by django's features and structure.
- cturner 17y agoWhatever it is, it's really fast.
- zedshaw 17y agoNope, not rails (troll). It's a web.py application combined with a Lamson application. The frontend is run through nginx and I use some heavy caching tricks to make it fast as possible. The primary design for hosting costs (scalability) are: 1) http://wiki.nginx.org/NginxHttpAdditionModule http://wiki.nginx.org/NginxHttpAdditionModule to serve static headers and footers so the framework doesn't. 2) Javascript determines the login state of a user and then displays user state links. 3) Generation of the site is "out of order" for convenience of generation/caching, and then javascript knits it back together. We'll explore more of this later. 4) Caching for about 5 minutes on most pages, depending on usage. 5) Use of http://wiki.nginx.org/NginxHttpProxyModule#proxy_store http://wiki.nginx.org/NginxHttpProxyModule#proxy_store to do page caching for content that needs to be dynamically generated very infrequently. 6) Gzip compression (should do precompression really) and other tuneups. 7) Using Lamson to accept posts via email so that they're processed off-line and statically generated. This is also really easy for people to use and easy to setup, so triple win. It's currently not close to a production setup, but I'm going for making it easy to host on a small server to keep costs low. Part of that is just not using the framework when possible. For statistics, right now the Nginx server is getting a modest 4-10 req/sec for html, but the backend is only serving about 1 request a minute thanks to all the above. Also the site really doesn't accept uploaded content via HTTP except say for photos. Hope that helps, I may blog about it more later.
- apu 17y agoWow, someone else using web.py, and that too for a "real" project! I always feel like a n00b for using such a stripped-down "framework" but after spending some time trying Pylons and Django, I found them both to be too "heavy-weight" for me. What do you like and dislike about web.py?
- zedshaw 17y agoI like web.py for this because it's tiny, fits HTTP real well (try doing REST with Django), and it's "just a library" so it's easy to mesh with Lamson. Also, I was bored. What I don't like about web.py is this: https://bugs.launchpad.net/webpy/+bug/435370 https://bugs.launchpad.net/webpy/+bug/435370 I have to hack that fix in to every web.py install because they're too arrogant to actually fix it properly, even when given the fix.
- jpeterson 17y agoZed, I know you mean well, but your wording in that bug report is extremely asshole-ish. Can't you point out flaws without being so snarky?
- idm 17y agoSeriously? A bug report that identifies a DOS condition gets flagged as "won't fix" -- and Zed's followup explains, with details, why it should be fixed, and what the fix should be. I tried, and I couldn't find anything asshole-ish about the bug report. It looks like good work to me.
- zedshaw 17y agoIt's not asshole-ish at all, it was just direct and made the point much clearer with the proper amount of urgency. This bug crashes sites consistently and is easily exploited. That's serious enough to warrant an immediate fix and release with an apology for the design. That's what I've done on my projects, and that's what I expect. Now, the question is why do you demand humility from me, but not from them?