

Scaling PHP Up, Out, and Around - cardmagic
http://blog.phpfog.com/2011/03/16/scaling-php-up-out-and-around/

======
gexla
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.

------
jrockway
_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.

~~~
true_religion
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?

~~~
rhizome
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.

~~~
IgorPartola
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.

~~~
jrockway
_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.)

~~~
IgorPartola
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.

~~~
jrockway
libmysqlclient sucks. :)

------
zentechen
How about adding hiphop-php from Facebook?

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

------
antihero
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?

~~~
Mikushi
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...

------
iaskwhy
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?

~~~
cardmagic
O(week) [edited, thanks!]

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

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

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

