Yep. And compared to Rails, something like mod_php is just so much faster and less resource hungry, it hurts. I use both regularly in production, and scaling the PHP side is almost trivial compared to the rails side.
I'm most surprised that PHP seems to be around an order of magnitude faster than Ruby on Rails, I knew it was faster, but didn't think it would be that much.
haha, all those hipster developers using rails can now eat the php guys shorts :)
Seriously though, this isn't news to anyone that does this professionally. The further up the abstraction curve you climb, the less performant the code will be. Ease of development vs run-time performance.
The reason I cited Rails is that its usually proposed as the better alternative in these anti-PHP threads. Most "high" performance PHP doesn't use one of the usual-suspects in the framework world and can easily beat Rails (and usually plain ruby too).
Edit: I should add "in my experience" to the end of that, I have no stats to hand.
I'd actually go so far as to say that the PHP ecosystem completely dwarfs the Rails ecosystem, and until my mom can upload a Ruby file to any cheap shared server and just have it work it always will.
You don't think Ruby on Rails requires the overhead of a server???
There are perfectly good and very sophisticated MVC frameworks available for PHP, such as CakePHP (one of the closer to Rails, even down to the command-line "baking" of models, controllers, etc.).
There are meaningful differences to development using both languages, but criticizing PHP because it was popularized independently of any specific framework is not one of them. Especially since there are plenty of situations (think dumb but scalable web services) in which the last thing you want to do is invoke the overhead of a framework in any language.
I think I'll stick with rails if I want cute DSLs and lots of magic ("… broadcast an event to update the frontend in real time …"). But sure, it's great that php has come a long way since php3.
That aside:
> It can handle more than 500,000 orders per month when hosted on a $6/month server.
Surely it can do more than 700 orders per hour, 1 order every 5 seconds?
> The only additional fees are for a CDN (if you want your assets to be served faster) and a domain name
Uh, so no managed database, but you recommend paying for a CDN before slapping Varnish in front of your static assets?
I get that php might be eminently usable at this point - but this seems like an odd pitch.
The link you yourself cite shows a fourfold speed advantage for procedural PHP over ROR. Not mentioned is the large memory footprint of a Rails process compared to a procedural PHP page. It's the usual phenomenon of trading off development time and complexity for performance. I'm sure if you wrote a web app in C, it would run even faster.
Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. You find yourself needing to understand the innards of what is a very complex environment, and dealing with an idiosyncratic development community that considers monkey-patching a neat programming techinique, and likes to publish its documentation in video format.
He doesn't seem to me to be saying 'don't use Rails'. He's just pointing out you should be fully aware of what you're getting into. Caveat scriptor.
Facebook, Yahoo, Flickr and Digg all use non-PHP solutions for the back end.
Rails can scale fine once you realize it's not magic; you take a hit from using a framework designed to make developers happy, not servers, but you can work around it — at the end of the day, Ruby isn't slow like people make it out to be.
I've worked with rails a lot over the years, including high traffic sites, and the general comment I'd make is that Rails scales more or less like PHP, but consumes far more ram per process doing so. Beyond that, whether it's good for your project probably depends a lot more on culture and the people involved than any technical distinction. Deploying rails was historically rather clunky, but that's been resolved over the last couple years thanks to folks like Heroku.
I'm not suggesting you use Drupal without a good reason, but if you're worrying about hypothetical scaling concerns before you've ever even touched PHP or Rails in your life, you're probably focusing on the wrong thing.
Both Rails/PHP are solid choices. If your app fits well within Rails' set of defaults and constraints, you should get to market quicker. PHP has its own set of advantages, such as the ease of procuring cheap hosting and the vast number of trained PHP developers out there that can help build/maintain anything you build.
since rails has so much convention, you can write a system that scales it as long as peopel follow that convention.
PHP is a free for all. Different frameworks do things differently and need to be scaled differently. Lots of people don't use frameworks. I think it will be hard to write a "one size fits all" infrastructure solution for PHP, like what Heroku did for Rails.
The "rails doesn't scale" mantra was discredited 5 years ago, when people realised that it scales exactly the same way as PHP. Remember, scalability != performance.
Here is my experience. I used Rails for one project of mine that requires processing of millions of data rows. Because the Rails ORM create an object for each data row, we end up using a lot of memory. We had to get a 2GB memory server to hold up the project. Even after we avoided the ORM (which removes the pleasure of coding in Rails), the memory usage was still high.
Sure, we could process the data rows outside of Rails in C but because the processing of data rows is an integral part of the project, that would mean coding 80% in C and 20% in rails. Not exactly an enjoyable experience.
So we rewrote it in PHP and avoid objects and use just functions and hashes/arrays. And it worked very well for us. The site render time drops from 0.8s to 0.03s. Memory usage rarely exceeds 100MB.
From knowing nothing to building a simple web app, PHP is faster.
If you already know RoR and have your dev machine and deployment environment all set up, then it's not hard to get a Rails app working. Rails has a significant advantage with the use of gems (and bundler, etc.) for easily adding complex features.
I still use PHP for my home projects most of the time because I haven't bothered to set up Rails on my VPS, so the effort it would take to do so just isn't worth it compared to how easily I can drop a PHP app in place. (I am using a framework in PHP too.)
But then, the author was talking about PaaS not setting up Ruby on a VPS. So in that case it's probably just about how comfortable the developer is with each language. I'm a bit more comfortable with PHP because I don't like debugging Ruby GEMs that use instance_eval black magic for DSLs and/or have to be inserted as Rack middleware. Not unless the project is large enough to make Ruby gems worth it.
(Eg. if I want good unit and integration testing. For home projects I rarely do integration testing. E.g. #2 was rack middle ware for REST API.)
While RoR is getting better in this respect, PHP is vastly better documented (both officially and all throughout the web) and the community is (at least, for now) superior to RoR. This is something that simply requires more time for RoR, as PHP has had quite a few years head start to get to where it is.
In practice, it honestly boils down to what you're doing and what's easier for you (and your team). If you want to test the waters, follow a few tutorials for each that you're unfamiliar with, and see what suits you better.
If you're using a shared server, you also have to make sure that your host supports RoR (most hosts don't). So that could be an extra expense to consider.
Me personally: I'm a php person. I prefer PHP + CodeIgniter, and I'm all happy :) RoR is fine and dandy, imo, but wasn't worth 9 years of PHP experience when PHP works amazingly well for everything I've ever asked of it.
reply