Scaling PHP Up, Out, and Around | Hacker News Reader

Scaling PHP Up, Out, and Around

blog.phpfog.com

51 pointscardmagic17 comments

This service doesn't seem to be at all like a "Heroku" of PHP" as it was marketed at one time. It seems that each app is simply running on one or more of it's own EC2 instances with the smallest plans (free tier and the smallest paid plan) running on micro instances. Those micro instances are horrible (generally slow, terrible I/O) and for the monthly fee they are charging, there are much better options. That probably explains why they only give one free app for the entire account, it would be too expensive to provide more than one free micro instance for everyone. Though I haven't been impressed by the AWS micro instances, PHP Fog apparently has an option to run on Rackspace cloud which is much better for the low end IMO.

Heroku doesn't put your applications on their own instances. I imagine they are also getting around the problem of crap low end EC2 instances by distributing all apps across clusters of the largest instances.

Not to bag on PHP Fog, they have created a lot of excitement in the PHP space. Personally, I prefer Heroku's model and for PHP I would rather just cut out the middle man and run my own VPS. It's nice not to have to deal with administration, but that's just one benefit of using Heroku, and not the most important for me.

Web servers are limited in the number of concurrent connections they can maintain (tubes aren’t big enough).

This doesn't really make sense -- maintaining a TCP connection requires no "tubes"; the limit comes from finite state storage: a finite state table, a finite number of file descriptors, and a finite amount of RAM in which to store the application-level connection contexts. These numbers turn out to be Really Fucking Big, so this is probably not affecting your application unless you are Google's IMAP servers or something.

By "maintain", he likely means that bandwidth to any particular server is constrained. Yes, you may be able to hold 10k connections open on your Wifi'd laptop, but if each connection only gets 1B/s is it really a useful webserver?

Any modern web server is going to be able to handle tons of connections, much more than a wifi laptop that can not yet be considered a modern web server. Beyond that, bandwidth is rarely the limiting factor. Framework/language weight, slow db queries, and javascript performance in the user's browser are much more prevalent concerns. In my experience it's always the db that falls over first, well before connection limits are reached.

Slow DB queries, yes. If your application does something stupid with SQL, your whole awesome C10K-solving epoll-based framework comes to a halt waiting for the database to read 1M rows off disk. Worst of all, your ORM likely hides the facts from you, producing left joins when you need inner ones, or worse not grouping the results so that a full join'ed result is returned when you only need the first and last tables.

More on topic, scaling web servers is not hard, just tedious. Scaling storage, especially if you need to use RDBMS's is the real trick.

If your application does something stupid with SQL, your whole awesome C10K-solving epoll-based framework comes to a halt waiting for the database to read 1M rows off disk.

No, a database connection is just another socket in your "awesome epoll-based framework".

Worst of all, your ORM likely hides the facts from you

Maybe if you're writing your app in BASIC? A good ORM doesn't hide the query logic from you, and there are plenty of popular languages that have good ORMs. The difference between using an ORM and not using an ORM is that you don't have a bunch of code to map SQL rows to application domain objects in your app. That's it.

(Note: Active Record and Class::DBI from 5 years ago aren't good ORMs. But people have written good ones in the intervening time, like DBIx::Class.)

To your first point, at least libmysqlclient blocks and any wrapper around it does too. To your second point, my most recent experience is with sqlalchemy, which is really pretty powerful, but also produces some hideous SQL when using the ORM layer. It does not hide the query logic from you, but conceals it just enough that I have to check every time that it is not lazy-loading 10,000 rows or not returning 10,000 rows when I only need 10.

libmysqlclient sucks. :)

How about adding hiphop-php from Facebook?

I think they'll do this. They spoke to me about adding phc support, so I expect HPHP to be on their roadmap.

Thing I don't get about things like PHPFog, is how do you manage dependencies (my app depends on my shared libraries), data storage (postgresql, for instance), Memcached, application configuring, etc?

Agreed, i asked on Twitter about these kind of stuff (more specifically about Redis, but that applies to anything), never got an answer. Right now, i have an access to PhpFog, it's "nice", but, without the ability of getting Redis, or Sphinx prevents me to use it as my little laboratory for small apps and stuff. I guess i'll stick with AWS for now...

Just a quick note: on the top of the page there is a broken link to "Pricing".

I am looking forward for a service like this, any idea when this will be open to the general public?

O(week) [edited, thanks!]

Can we ignore the constant factor and say it's O(week)? ;-)

Thanks man.... I have ammmo for the arguments now.:-)

Who are you arguing with? Ignore the haters and use whatever language you like and are most productive with.

Reply on news.ycombinator.com