HN Explorer

Ask HN: Are dynamic languages fast enough for dynamic sites on low-end hardware?

4 points by vanilla-almond ↗ HN
If you have low-end server hardware (e.g. 1GB or 2GB memory shared CPU hosting) will a dynamic scripting language (Python, Ruby, PHP, Javascript) perform fast at serving dynamic pages? At what point will the language struggle where more performant languages might breeze through?

I know this might a bit like asking how long is a piece of string, but let's say 1000 users are concurrently accessing the site's pages which are mostly being dynamically generated. Would this be a breeze for dynamic languages on low-end hardware?

4 comments

[ 5.1 ms ] story [ 19.3 ms ] thread
backslash_16
I'm trying to write a good short answer or TL/DR and don't think I can. If you want a pithy one, at 1000 concurrent users (with no other information given) the answer is your bottleneck probably won't be Python or Ruby.

The real answer depends on some assumptions I'm making and questions

Assumption #1 - You're doing server side rendering because you talk about dynamically generated pages and not API response times.

Assumption #2 - You're using a database and it will be on the same instance as the web server.

Assumption #3 - You have one web server instance.

  - What does shared CPU really mean? Is there a guarantee on a lower bound of the resources you will have?
  - When the page is dynamically generated is it mostly calls to a DB and stitching that information together in a template?
  - When the page is rendered can it require a lot of computation? An example of that is a portal where someone asks for a report with custom aggregations you're doing in the application layer and not DB layer
  - Does rendering a page require calls to any other services? 
  - Do these services have RPS and average latency guarantees?
  - Are you using a CDN or serving everything from your one web server instance?
A web app that is focused on serving static assets with little customization, say putting a user name in the header and a separate profile page, could be fine if you use a CDN for the static assets and don't call the DB excessively.

If you're calling the DB 200 times to generate a page, doing long running queries, or a lot of computation in the app layer you might be in trouble. (With my hypothetical 200 DB calls to load a page you're certainly not in a great spot :))

Does anyone know how to format a list? I can't figure out the magic incantation and https://news.ycombinator.com/formatdoc isn't helping much.

dith3r
It depends on many factors. How many requests you predict? What type of application you are building? What size of hot data you will be dealing with? Your workflow is cachable? Dynamic languages are rather unefficient at scale, but allow you to prototype and most of performance comes from proper data structures or algorithms.
bjourne
There are porn sites serving 100k+ uniques/day written in Ruby or Python and hosted on worse hardware than yours. 1000 simultaneous users is a breeze.
karmakaze
Doing some napkin estimating: 1000 users loading a page each per minute is 16.67 page renders per second (or 60 ms per page assuming one cpu thread). If they're reloading every 10s that's 10 ms per page. At that rate even a compiled language may not keep up with the db being the bottleneck.

That said, if any of the page renderings can be shared between users, such as using a framework that can do page fragment caching then you can approach that level especially if you can cache entire responses using nginx.