6 ms·

I work at a dev shop and we've been developing web apps for 10 years or so. We've run through PHP, Rails, Node, Python (Django) and lately Go. For the types of

by conorh 10y ago

I work at a dev shop and we've been developing web apps for 10 years or so. We've run through PHP, Rails, Node, Python (Django) and lately Go. For the types of apps that we develop, web apps, or perhaps web apps with an API. We have found that ruby/rails is our fastest and happiest combination. It is the slowest combination in terms of code execution speed, but in terms of speed of development and developer happiness it Just Works (tm) and allows us to get reasonable code developed at lower cost. We deploy many sized apps from tiny one server apps to small/mid sized apps with 100k users, but we've never found the speed of Ruby to be a big issue - usually it is everything else, testing, maintainability etc. If speed is an issue we've always been able to work around it without too much difficulty, and these days if we know we will need the speed or scaling we'll resort to Go, but we find that our development time increases somewhat.

collyw 10y ago
The last two apps I have inherited have been in Python (Flask and Django). If they were slow, its because they were poorly written (one page makes over 1000 database calls - it could be done in less than ten). Sort all that crap out before worrying about the language.
- roflc0ptic 10y ago
  In a talk once I heard web applications described as "database skins." Maybe it's hyperbole, but the general point seems sound - most web apps are CRUD, and the slow point in most applications is IO. I suspect not doing dumb IO is 9 times out of 10 the solution to performance problems. That said, working against oracle databases with Django is slow as all get out. Something about the driver requires numbers to be converted from number to string back to number, while calculating whether it's an integer/decimal/whatever. Simple queries returning 1000 rows could take ten seconds. I spent several days running that down. The analysts at my shop blamed django, which was pretty unfortunate.
  - combatentropy 10y ago
    > I heard web applications described as "database skins." Not a bad description. > the slow point in most applications is IO The slowest part of web apps in my decade of experience is the database, yes, if that's what you mean by IO. Reading and writing files, also IO, is very fast though. A database can be very fast too (I've mostly used Postgres). Or it can be dog slow. It's just like how some programmers are 100 times better than other programmers. One SQL query is 100 times faster than another, and both get the same result. And it's not usually something simple like adding a column index. Usually it's a matter of a sub-select or some other squirrelly way of combining tables or aggregating a result. I wish more programmers learned SQL --- I mean really learned it through and through --- than concentrated on the latest fads.
    - iofj 10y ago
      > I wish more programmers learned SQL --- I mean really learned it through and through --- than concentrated on the latest fads. And miss out on all the coffee breaks afforded by programmers just looping over entire databases in a horribly inefficient ORM ? Because all this condition abstraction in the ORM is really hard to use ... Don't worry though : they're optimizing it. I hear they're upgrading to run the loop in 100 threads instead of just one. Surely that will accelerate things a lot ! And if that doesn't work, we always have memcache, don't we ? Also we can now use cloud databases to spread the load, surely that'll help (I'm looking forward for the first double-digit page refresh, measured in dollars) (Having worked years for hosting providers where 20-30% of my job was making PHP/Python/Ruby/sometimes even Java applications run faster, and achieving 50x improvements on a regular basis, this had to get off my chest. And yes I've seen people implement mail address lookups by iterating over the ORM-provided collection ... and then show 50 mail addresses, wondering why the page load time was bordering on 3 digits when measured in minutes. Not even just once)
- hueving 10y ago
  I can't emphasize this enough. I'm always blown away by how quickly engineers will chalk a slow application up to the language it's written without even doing a minimal amount of profiling. In almost every case it has been severely limited by waiting on a massive number of backend calls, DB reads, system calls, etc and became orders of magnitude faster after fixing those silly mistakes. profile profile profile before you waste a ton of engineering effort on a rewrite that may buy you absolutely nothing.
  - stcredzero 10y ago
    I'm always blown away by how quickly engineers will chalk a slow application up to the language it's written without even doing a minimal amount of profiling. The more things change, the more they stay the same!
  - pbowyer 10y ago
    I now install AppNeta TraceView [0] whenever I launch a site. The free plan is fine for initial profiling and it's useful to see what matters under a production load. And the paid plan has proved itself. NewRelic is similar, but I find the TraceView interface much much better. 0: https://www.appneta.com/products/traceview/ https://www.appneta.com/products/traceview/
- bbody 10y ago
  Maybe part of these frameworks (Rails, Flask, etc.) reputation comes from newbies doing a lot of database calls because the framework makes it easy for them to do it. Edit: More clarity.
  - collyw 10y ago
    Django is probably pretty bad for this. The ORM is easy to use for easy stuff, but trying to write efficient queries with it takes a fir bit of practice.
carsongross 10y ago
CPU in the web layer is just not the bounding issue in the vast majority of web apps: network access and query optimization are the bad ones. Where you have big-data like stuff going on, you can and should kick out to a job-processing model based on whatever technology you'd like. From what I see in our perf logs, a faster string concatenation layer in ERBs would be the place where rails could save a lot of CPU cycles, but it really wouldn't matter except for very large tables, and I use intercooler to keep them relatively small w/ ajax paging or infinite scrolling, depending on the UI.
stcredzero 10y ago
I work at a dev shop and we've been developing web apps for 10 years or so. We've run through PHP, Rails, Node, Python (Django) and lately Go. For the types of apps that we develop, web apps, or perhaps web apps with an API. We have found that ruby/rails is our fastest and happiest combination. It is the slowest combination in terms of code execution speed, but in terms of speed of development and developer happiness it Just Works (tm) and allows us to get reasonable code developed at lower cost. This reflects what devs saw in Smalltalk. Business apps ran with sufficient speed on 486 CPUs with interpreters and relatively primitive JIT VM. Business apps were typically bound by I/O to databases and other back-end servers. This didn't prevent bad developers and pointy-haired bosses from blaming Smalltalk execution speed. That was almost never borne out with profiling and where it was, judicious implementation of a particular algorithm in C/C++ usually solved it with a minimum of fuss.
joe_the_user 10y ago
If you have do just simple development (web or otherwise) at a small scale then your language's speed indeed doesn't matter very much. But I think people still underestimate how much development isn't that. Most startups involve things that need to scale now or things that will need to scale. A lot of scientific development need complex algorithms. A significant portion of corporate development needs speed because it's operating at scale or because it's one piece of a long pipeline of import/export applications etc (another portion of corporate development doesn't need speed but good luck finding the discipline to get your manager to distinguish the two cases). And there's embedded and various other things. "Don't worry about speed, we're just prototyping here" is a saying that always signals danger - a large organization often will want to deploy whatever monster once they know it works. So really, it seems like Ruby is indeed great for apps for medium-sized brick-and-mortar business wanting a web presence and there is a whole lot of that happening. However, Ruby being inherently slow in multiple dimensions means it's dangerous for many other use cases (dangerous because of the "it works? Why not keep using it" factor and the danger being you'll wind-up using after its slowness becomes a real headache).
- VeejayRampay 10y ago
  Medium sized brick and mortar companies such as Github, AirBnB, Shopify, Basecamp, Groupon, 500px, Capitaine Train (who just sold for 200 millions) and tons of other companies. Helped Twitter get off the ground as well. Now some of them might have moved some of their stuff off Rails/Ruby, but never prevented them from succeeding. It might actually have helped them iterate rapidly in the first few years. The idea that Ruby (or any other language for that matter) is only good enough for some scale doesn't actually translate into reality.
  - joe_the_user 10y ago
    Helped Twitter get off the ground as well. Now some of them might have moved some of their stuff off Rails/Ruby, but never prevented them from succeeding. I can only answer by parable. Start from the point of view of a group of carpenters asking "is cardboard strong enough to build houses from" and you may a consensus until someone chimes in to say "but a lot of people have made a lot of money selling cardboard houses that survived just long to let them gather investors and money for building real houses." Sure, that may well be true but it's really going to change the view of carpenters.
bbody 10y ago
Whenever I read articles about Rails performance I often think about the saying from the early days of Twitter, "Rails doesn't scale". However as most of the comments have said here, the biggest factor that typically affects an app is I/O. There are plenty of large companies that run Rails and for most up and coming startups Ruby on Rails is probably enough to validate your idea.

by conorh 10y ago

collyw 10y ago

The last two apps I have inherited have been in Python (Flask and Django). If they were slow, its because they were poorly written (one page makes over 1000 database calls - it could be done in less than ten). Sort all that crap out before worrying about the language.

roflc0ptic 10y ago
In a talk once I heard web applications described as "database skins." Maybe it's hyperbole, but the general point seems sound - most web apps are CRUD, and the slow point in most applications is IO. I suspect not doing dumb IO is 9 times out of 10 the solution to performance problems. That said, working against oracle databases with Django is slow as all get out. Something about the driver requires numbers to be converted from number to string back to number, while calculating whether it's an integer/decimal/whatever. Simple queries returning 1000 rows could take ten seconds. I spent several days running that down. The analysts at my shop blamed django, which was pretty unfortunate.
- combatentropy 10y ago
  > I heard web applications described as "database skins." Not a bad description. > the slow point in most applications is IO The slowest part of web apps in my decade of experience is the database, yes, if that's what you mean by IO. Reading and writing files, also IO, is very fast though. A database can be very fast too (I've mostly used Postgres). Or it can be dog slow. It's just like how some programmers are 100 times better than other programmers. One SQL query is 100 times faster than another, and both get the same result. And it's not usually something simple like adding a column index. Usually it's a matter of a sub-select or some other squirrelly way of combining tables or aggregating a result. I wish more programmers learned SQL --- I mean really learned it through and through --- than concentrated on the latest fads.
  - iofj 10y ago
    > I wish more programmers learned SQL --- I mean really learned it through and through --- than concentrated on the latest fads. And miss out on all the coffee breaks afforded by programmers just looping over entire databases in a horribly inefficient ORM ? Because all this condition abstraction in the ORM is really hard to use ... Don't worry though : they're optimizing it. I hear they're upgrading to run the loop in 100 threads instead of just one. Surely that will accelerate things a lot ! And if that doesn't work, we always have memcache, don't we ? Also we can now use cloud databases to spread the load, surely that'll help (I'm looking forward for the first double-digit page refresh, measured in dollars) (Having worked years for hosting providers where 20-30% of my job was making PHP/Python/Ruby/sometimes even Java applications run faster, and achieving 50x improvements on a regular basis, this had to get off my chest. And yes I've seen people implement mail address lookups by iterating over the ORM-provided collection ... and then show 50 mail addresses, wondering why the page load time was bordering on 3 digits when measured in minutes. Not even just once)
hueving 10y ago
I can't emphasize this enough. I'm always blown away by how quickly engineers will chalk a slow application up to the language it's written without even doing a minimal amount of profiling. In almost every case it has been severely limited by waiting on a massive number of backend calls, DB reads, system calls, etc and became orders of magnitude faster after fixing those silly mistakes. profile profile profile before you waste a ton of engineering effort on a rewrite that may buy you absolutely nothing.
- stcredzero 10y ago
  I'm always blown away by how quickly engineers will chalk a slow application up to the language it's written without even doing a minimal amount of profiling. The more things change, the more they stay the same!
- pbowyer 10y ago
  I now install AppNeta TraceView [0] whenever I launch a site. The free plan is fine for initial profiling and it's useful to see what matters under a production load. And the paid plan has proved itself. NewRelic is similar, but I find the TraceView interface much much better. 0: https://www.appneta.com/products/traceview/ https://www.appneta.com/products/traceview/
bbody 10y ago
Maybe part of these frameworks (Rails, Flask, etc.) reputation comes from newbies doing a lot of database calls because the framework makes it easy for them to do it. Edit: More clarity.
- collyw 10y ago
  Django is probably pretty bad for this. The ORM is easy to use for easy stuff, but trying to write efficient queries with it takes a fir bit of practice.

carsongross 10y ago

CPU in the web layer is just not the bounding issue in the vast majority of web apps: network access and query optimization are the bad ones. Where you have big-data like stuff going on, you can and should kick out to a job-processing model based on whatever technology you'd like. From what I see in our perf logs, a faster string concatenation layer in ERBs would be the place where rails could save a lot of CPU cycles, but it really wouldn't matter except for very large tables, and I use intercooler to keep them relatively small w/ ajax paging or infinite scrolling, depending on the UI.

stcredzero 10y ago

I work at a dev shop and we've been developing web apps for 10 years or so. We've run through PHP, Rails, Node, Python (Django) and lately Go. For the types of apps that we develop, web apps, or perhaps web apps with an API. We have found that ruby/rails is our fastest and happiest combination. It is the slowest combination in terms of code execution speed, but in terms of speed of development and developer happiness it Just Works (tm) and allows us to get reasonable code developed at lower cost. This reflects what devs saw in Smalltalk. Business apps ran with sufficient speed on 486 CPUs with interpreters and relatively primitive JIT VM. Business apps were typically bound by I/O to databases and other back-end servers. This didn't prevent bad developers and pointy-haired bosses from blaming Smalltalk execution speed. That was almost never borne out with profiling and where it was, judicious implementation of a particular algorithm in C/C++ usually solved it with a minimum of fuss.

joe_the_user 10y ago

If you have do just simple development (web or otherwise) at a small scale then your language's speed indeed doesn't matter very much. But I think people still underestimate how much development isn't that. Most startups involve things that need to scale now or things that will need to scale. A lot of scientific development need complex algorithms. A significant portion of corporate development needs speed because it's operating at scale or because it's one piece of a long pipeline of import/export applications etc (another portion of corporate development doesn't need speed but good luck finding the discipline to get your manager to distinguish the two cases). And there's embedded and various other things. "Don't worry about speed, we're just prototyping here" is a saying that always signals danger - a large organization often will want to deploy whatever monster once they know it works. So really, it seems like Ruby is indeed great for apps for medium-sized brick-and-mortar business wanting a web presence and there is a whole lot of that happening. However, Ruby being inherently slow in multiple dimensions means it's dangerous for many other use cases (dangerous because of the "it works? Why not keep using it" factor and the danger being you'll wind-up using after its slowness becomes a real headache).

VeejayRampay 10y ago
Medium sized brick and mortar companies such as Github, AirBnB, Shopify, Basecamp, Groupon, 500px, Capitaine Train (who just sold for 200 millions) and tons of other companies. Helped Twitter get off the ground as well. Now some of them might have moved some of their stuff off Rails/Ruby, but never prevented them from succeeding. It might actually have helped them iterate rapidly in the first few years. The idea that Ruby (or any other language for that matter) is only good enough for some scale doesn't actually translate into reality.
- joe_the_user 10y ago
  Helped Twitter get off the ground as well. Now some of them might have moved some of their stuff off Rails/Ruby, but never prevented them from succeeding. I can only answer by parable. Start from the point of view of a group of carpenters asking "is cardboard strong enough to build houses from" and you may a consensus until someone chimes in to say "but a lot of people have made a lot of money selling cardboard houses that survived just long to let them gather investors and money for building real houses." Sure, that may well be true but it's really going to change the view of carpenters.

bbody 10y ago

Whenever I read articles about Rails performance I often think about the saying from the early days of Twitter, "Rails doesn't scale". However as most of the comments have said here, the biggest factor that typically affects an app is I/O. There are plenty of large companies that run Rails and for most up and coming startups Ruby on Rails is probably enough to validate your idea.