Ask HN: What are other “major components” of highly performant web applications? | Hacker News Reader

Ask HN: What are other “major components” of highly performant web applications?

9 pointsarthurcolle9 comments

I have been messing around with Rails for the past year and it has got me more attuned to what is needed/important when building web apps.

I have seen the words before, but things like memcached, HAProxy, etc - I didn't appreciate why they were useful until I saw the limits of a simple server + db combo.

I was wondering, besides the following:

http server (WEBRick or Puma, Apache)

database + database server (MySQL, postgres, etc)

Load balancer (HAProxy)

Caching middleware (memcached)

Sessions (Redis)

What are other major components of web apps that are critical for building high performance apps?

Thanks in advance!

View on HN

There are many different paths by which user can access the contents of your web app. For high performance apps, you'll want to optimize this process. Here are two suggestions:

- Use a CDN to serve static content without the need to serve the content out of the origin server every request.

- Create instances of your application in multiple regions. The shortest path to your web app varies based on where the user is in the world. Multiple regions can minimize the latency introduced via the hops s/he must make.

Have a look at "Web Operations". It deals with all the components of building and operating a large web application. http://www.amazon.com/Web-Operations-Keeping-Data-Time/dp/14...

Depending on the app, a caching proxy (or CDN) with ESI support (and the appropriate ESI tags in the output) can vastly improve performance while retaining user-specific page content.

Personally I like varnish for this role.

Tuning your database indexes and monitoring cpu usage, ram usage and queued http request counts are a few that come to mind.

I have $25/month Heroku professional dynos, and I keep maxing out 512MB ram, any advice on what to work on to lower that? It's ridiculously high I know, but worth a shot.

The best thing to do is profile your app's performance, make a change and observe the results. It will help you make sure that your effort and money are actually improving things. New Relic has been great for this, and I've also heard good things about Data Dog. Run your app for a while with one of those in place, observe where the bottlenecks are, then come up with experiments to test whether you can improve performance.

If it's a Rails app, two things spring to mind as first things to try once you have profiling in place:

- lower the number of web server workers and/or threads (depending on what you're using)

- Ruby 2.1's garbage collector is really not well suited to web apps because it will often promote objects from a single request to the long-lived generation, even though they will not be needed again. Going from 2.0 to 2.1 nearly doubled the memory usage of one of our apps. 2.2 is doing much better.

You might also want to see if you can offload any processing of tasks that can be queued using something like Sidekick or Resque.

There's a bunch of other things you could do but you really need to work out why your app isn't performing as you'd like first.

I'm using Rubinius, the C++ implementation of Ruby in conjunction with Puma. (http://rubini.us)

I'll definitely check out Data Dog and New Relic, thanks for the tip

Rubinius was the culprit! 250MB alone! WTF!

You're going to need queues is you want to make it scale.

Reply on news.ycombinator.com