TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Where/How can I learn more about general webapp maintenance?

41 点作者 ha470超过 13 年前
Particularly things like fault tolerance, speed, unit testing, code abstraction, etc.<p>I've been hacking away/making webapps for a while and although they're functional they aren't optimized for heavy use. Now that I'm working on a startup/production application, I've realized that general maintainance is a skill-set I really haven't perfected. Any good sources for these - especially related to Ruby/Rails? I'm working through code-complete/pragmatic programmer for general good code practice, but would love some other books/blogposts/anything on the matter.&#60;p&#62;Thanks so much!

7 条评论

mattmanser超过 13 年前
<p><pre><code> 1. Database, database, database 2. Database 3. It's probably your database unless you're doing something CPU or disk intensive, for example resizing and prettifying pictures, rendering a 3d image, etc. Realize that these days looping a few thousand times is trivial. 4. It's your database </code></pre> Starting with <i>fault tolerance, speed, unit testing, code abstraction, etc.</i> is starting at the wrong point. 90% of performance problems are at the database level.<p>What's most likely wrong with performance in a webapp:<p><pre><code> 1. No/bad indexes/missing foreign keys on your db 2. Stupid joins 3. You're doing stupidly complicated things in an ORM 4. You're doing complicated things in the DB instead of loading a large chunk into memory and doing calculations or aggregations in code. Simple DB queries are a lot faster than you think they are. Complicated ones are a lot longer than you think they'll be. There are weird gotchas in DBs like using a function in a where or select clause will cause a massive performance hit. 5. You're not caching into memory or something like memcached things that changes infrequently but are queried regularly. Memcached is actually overkill most of the time. Actually think about how much memory storing X would take compared to how much memory your machine has. Be surprised at how insignificant it is these days. 6. 1-5 are especially true if you're using Mysql - It's great and all, but all the other big DBs piss all over it for out of the box performance. You have to give it some love. I expect some dissent here. They're wrong. MS SQL is a shit ton better at handling a poorly designed db/db queries out of the box than mysql. I can't stress this enough. </code></pre> tl;dr Start looking at your database performance before anything else.
评论 #3037127 未加载
评论 #3028334 未加载
pbh超过 13 年前
I'm not an expert, but this is what I've cobbled together as a fellow Ruby/Rails startup person.<p><i>Fault</i> <i>Tolerance</i>: Just use Heroku. We've seen maybe an hour of downtime in a few months?<p><i>Speed</i> (and fault tolerance): Cache everything you can, assets on S3/CF.<p><i>Testing</i>: Rails Test Prescriptions by Noel Rappin [<a href="http://pragprog.com/book/nrtest/rails-test-prescriptions" rel="nofollow">http://pragprog.com/book/nrtest/rails-test-prescriptions</a>]. Then you can choose what you like, but I like Test::Unit, Mocha, FactoryGirl.<p><i>Code</i> <i>Abstraction</i>: Rails is already pretty sensibly organized, and if MVC + tests + static assets is not a good fit for your webapp, you really should not be using it in the first place. One minor point: Noel and others will tell you to use skinny controllers.<p>Curious what other people consider best practice for Ruby/Rails startups.
评论 #3027806 未加载
bricestacey超过 13 年前
I've heard good things about New Relic for performance testing.<p>MiniTest, which is built into ruby 1.9 has a full suite including performance tests. It's really cool because you can measure e.g. whether an algorithm scales linearly or not.
评论 #3027760 未加载
rprime超过 13 年前
A quick tip would be to run everything process intensive in the backend, don't waste frontend resources with API calls, data processing etc, got something that takes more than 200ms to run, place it in a job que and do the processing later.<p>Some tools for the job: <a href="https://github.com/defunkt/resque" rel="nofollow">https://github.com/defunkt/resque</a> <a href="https://github.com/tobi/delayed_job" rel="nofollow">https://github.com/tobi/delayed_job</a><p>Also don't forget to cache. You shouldn't worry too much if you do these two properly.
评论 #3028531 未加载
nfm超过 13 年前
From a performance point of view: test and measure! Find the worst bottleneck, and reduce it. Rinse and repeat.<p>NewRelic is a great tool to help you do this.<p>Common performance problems to look out for in Rails are:<p>* Missing database indexes<p>* Long running code (eg PDF generation, file uploads to a third party) that should be put in a job queue<p>* Innocent looking ActiveRecord calls that use N+1 queries or fetch way too much from the DB and the result set is further reduced in Ruby
guard-of-terra超过 13 年前
You can read on various massively scalable webapps architecture. <a href="http://highscalability.com/" rel="nofollow">http://highscalability.com/</a> seems to aggregate those, and you can find articles and slides published by the developers of more services if you do some googling.<p>The key to speed and load tolerance is massive multilevel caching; every service does caching differently but they all do.
etothep超过 13 年前
Pick up Release IT (<a href="http://amzn.com/0978739213" rel="nofollow">http://amzn.com/0978739213</a>) from the Pragmatic guys. While many of the examples and stories are based on Java webapps there is something in there regardless of which platform you are building atop.<p>Oh, and don't ever establish a blocking connection without a timeout or some other mechanism to abort it.