I found this particularly interesting:
"Our site is coded, I’d say, 90% in PHP. All the front end —
everything you see — is generated via a language called PHP. He is
creating HPHP, Hyper-PHP, which means he’s literally rewriting the
entire language. There’s this distinction in coding between a scripted
language and a compiledlanguage. PHP is an example of a scripted
language."
as well as
"We’re going to reduce our CPU usage on our servers by 80%, so
practically, users will just see this as a faster site. Pages will
load in one fifth of the time that they used to."
I'm surprised that anyone would think its an easy undertaking to
rewrite PHP as a compiled language. I can understand than APC/opcode
caches don't provide a sufficient performance boost for a behemoth
site like Facebook. But I fail to see why rewriting the whole
language is a better option than moving a lot of their code from PHP
scripts to PHP extensions written in C. I'm also skeptical that
reducing CPU usage by 80% correlates to such a large improvement in
page load time. When loading a page the usual bottlenecks are the
network and the number of requests that the page has to make. To see
an improvement this large, FB must have already optimized that side of
the equation as much as it can.
--
Oscar Merida
* http://OscarM.org - random thoughts on my blog
* http://SoccerBlogs.net - your daily soccer feed
* http://FutBoliviano.com - bolivian soccer, futbol de altura
Unless, of course, 80% of the page-load time is 100% CPU-busy.
Typical comparisons of processor and memory access versus disk I/O access generate ratios of nanoseconds to milliseconds - several orders of magnitude. As Brandon S. has written elsewhere, there are some things you should not tune.
Best to all,
Ray
-----Original Message-----
From: washington-...@googlegroups.com [mailto:washington-...@googlegroups.com] On Behalf Of Oscar Merida
Sent: Thursday, January 14, 2010 10:12 AM
To: DCPHP PHPDC
Subject: [dcphp-dev] Facebook rewriting PHP?
Morning all - I'm reading this article and its a great insight into how Facebook uses the data it collects as well as PHP.
I found this particularly interesting:
"Our site is coded, I'd say, 90% in PHP. All the front end - everything you see - is generated via a language called PHP. He is creating HPHP, Hyper-PHP, which means he's literally rewriting the entire language. There's this distinction in coding between a scripted language and a compiledlanguage. PHP is an example of a scripted language."
Much less CPU optimizations on the server side of things. See
http://developer.yahoo.com/performance/rules.html
"80% of the end-user response time is spent on the front-end. Most of
this time is tied up in downloading all the components in the page:
images, stylesheets, scripts, Flash, etc. Reducing the number of
components in turn reduces the number of HTTP requests required to
render the page. This is the key to faster pages."
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en
Steve
"Courage is not the absence of fear, but rather the judgment that something else is more important than fear." ~ Ambrose Redmoon
While I'm not intimately familiar with the internals of PHP itself, my guess is that PHP compiles the source into opcodes, which is then translated into other computer-readable formats. Facebook's goal here is probably to have a compiler that renders the code executable for the machine it's running on, without having to figure out the details of the libraries. They're essentially standardizing it.
Here's a little more public info:
http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-runtime.aspx
Disclosure: We (Blue Parabola) got a technology preview recently and
we have some limited involvement in what they're working on and what
they may or may not be announcing eventually.
keith
I wonder whether companies will start looking to languages like "Go"
when they need that completely different scale of performance. ... My
complaint with "Go" is no exceptions; if I were able to get over that,
it looks like it has some interesting qualities. (I don't think I
could get over that missing feature, though, for a software project of
any size.)
Hans
On Jan 31, 8:44 am, "mailingli...@caseysoftware.com"
<keith.ca...@gmail.com> wrote:
> On Jan 14, 11:07 am, Joshua Boyd <joshua.b...@endeavorsystems.com>
> wrote:
>
> > A few PHP compilers already exist. phpc and roadsend. Mostly experimental
> > though.
>
> Here's a little more public info:http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-run...
And we're allowed to comment on it. Here are Blue Parabola and php|
architect's positions on things:
http://www.phparch.com/main/news/view/68/Announcing_our_support_for_Facebook_s_HipHop
http://blueparabola.com/blog/announcing-our-support-facebooks-hiphop
kc
* It's nothing like FastCGI or does anything with FastCGI at all. When you
run the "compilation" step it actually optimizes everything down to C++ and
then compiles that.
* Therefore, you don't deploy it with the normal Apache/PHP combo, you deploy
it instead of them normal combo. It creates one big binary that serves as its
own server.
* Yes, it runs independent of the Zend Engine. It's irrelevant to this
application - http://twitter.com/nateabele/status/8552203049
* Yes, Facebook is running this in production now and they have been for a
year+. They built this because APC, etc weren't fast enough for them.
* Yes, it will be released Open Source, most likely under the PHP License.
* Yes, it fundamentally changes your deployment process... now if we just had
a nice Ant-like tool to help us? *cough*Phing*cough* ;)
* No, once the binary is created, you can't modify it without rebuilding a
new version. So no more "editing files on production".
* No, it won't make you SQL queries any faster. If your queries suck now,
they'll suck after - http://twitter.com/rasmus/status/8552927895
* No, it doesn't support 100% of PHP currently. It supports upwards of 90% of
functions.. but this may be a good thing as "eval()" is currently in the
non-supported list.
* No, web2project is not compatible using this yet. That's on the agenda to
get prepared for our own offerings. Rumor has it that a smart WordPress guy is
looking at it too - http://twitter.com/technosailor/status/8553031318 ;)
Overall, what's the point?
You write PHP and it runs with the speed of C. Facebook (and others) have
already seen a 50% performance improvement -
http://twitter.com/rasmus/status/8552893110
kc
jproffer wrote:
> Reminds me of C++ Server Pages (http://www.micronovae.com/CSP.html) -
> pretty sad that they never expanded beyond the Windows platform, or
> opensourced their product (considering its free to begin with).
--
D. Keith Casey, Jr.
CEO, CaseySoftware, LLC
http://CaseySoftware.com
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en
What are some other things it does not support? I know more official
info will be published soon, but it seems that you are already working
with it. Thanks!
--
Svemir Brkic
sve...@symplicity.com
Symplicity Corporation
http://www.symplicity.com
That's one of the things I can't get into yet. ;) In our testing, a scary
number of open source projects use "eval()" though... WordPress, Drupal are
just the most prominent ones.
Regardless, I missed the line in the post that HipHop is being released
tonight via GitHub and it is *officially* under the PHP license.
kc
Frameworks that include zillions of files will probably see a huge
improvement - if this thing indeed results in a single binary.
Even when using opcode cache, and without spending much CPU time, your
ability to handle concurrent requests is likely to improve a lot.
Depending on the file system etc. you may not see any difference with
one, five, or ten requests, but keep increasing the number and you will
be pleasantly suprised :-)
P. S. Above statement is based on a comparision between "all classes in
one file" vs. "a bunch of included classes" and may not be entirely (or
at all) representativ of "regular zend framework page" vs. "hip hopped page"
<snip>
> * Therefore, you don't deploy it with the normal Apache/PHP combo, you
> deploy it instead of them normal combo. It creates one big binary that
> serves as its own server.
>
<snip>
> Overall, what's the point?
>
>
> You write PHP and it runs with the speed of C. Facebook (and others) have
> already seen a 50% performance improvement -
> http://twitter.com/rasmus/status/8552893110
>
Additionally, you can now write and distribute php single end-user
desktop-type applications as one or two files in a zip archive. Just
add SQLite. This is HUGE.
Correct. Facebook's stated goal is to allow PHP developers to continue writing
*in* PHP but get all the benefits of compilation.
Not surprisingly, Marco talks about it here -
http://blog.tabini.ca/2010/02/hiphop-what-you-need-to-know/
Can CaseySoftware.com on Dreamhost use it? Not a chance.
Can the Library of Congress (internally hosted dedicated servers) use it?
Yes.. and then handle twice as much traffic with the same setup.
kc
jproffer wrote:
> I imagine that while this is probably a great thing, it would see very
> limited use. What real-life scennario would this prove useful,
> especially considering most hosting companies won't be able to run your
> standalone application unless you purchase a VPS or dedicated server.
> I'm sure the distributed applications will also have some platform
> limitations, and still require you set up a database on the target
> machine, so its not like you can just compile your new CRM application
> and send it to a client to run in windows? I also imagine this will
> have other problems like upgrading, port conflicts, etc.
--
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en
what about sites that need read/write access to directories. Like, image and video processing/distribution sites? Since the app compiles everything into a binary, how does it translate paths that would normally be within directories in the web root.
*Excellent catch*
That's actually the *one* thing that makes web2project incompatible with it.
We've put it on the agenda for our v2.0 release.
kc
kc
Svemir Brkic wrote:That's one of the things I can't get into yet. ;) In our testing, a scary number of open source projects use "eval()" though... WordPress, Drupal are just the most prominent ones.
* No, it doesn't support 100% of PHP currently. It supports upwards of
90% of functions.. but this may be a good thing as "eval()" is currently
in the non-supported list.
What are some other things it does not support? I know more official info will be published soon, but it seems that you are already working with it. Thanks!
This HipHop thing is interesting, perhaps in much the same way as
HipHop music: it feels like a hack. -- And I mean that respectfully
in both cases; I like hip-hop music, and appreciate how it pays homage
to R&B roots, remixing/reinterpreting them, etc; and I think that the
idea of taking one language and building it out to something else is
also something I should support. After all, I've embroiled myself in
code generation tools (e.g. Propel) that are operating on the same
philosophical groundwork. But I also believe that there's a general
rule like "if you need code generation, there's something wrong [in
your design or in the tools you've chosen or ...]" ... so those tools
also feel like hacks.
I guess the "hack" here is implicit in anything that's trying work
with what ya got. Another analogy is the DVR, the hack to fix the
problem that people want to watch TV programming when they want, not
when it's played. All indications in content delivery trends suggest
that we will look back and laugh about days when we needed DVRs. But
they provide a valuable service now (and probably for a number of
years to come). Similarly, I would hope (and expect) that the HipHop
project would become obsolete in the future too. It doesn't seem
unreasonable to expect that someone could write a PHP virtual machine
that performed as well as the compiled code. There are benchmarks
that show the JVM runs [some code] faster than optimized C++, so this
seems like a theoretically attainable goal. After all, since there's
nothing being added here, it seems like if there was a virtual machine
that could transparently compile PHP into machine bytecode, that'd
have the same effect (if not better) -- and skip the clumsy C-code
middleman.
I think also interesting (more interesting, honestly) is the idea of
compiling PHP (and other dynamic languages) to Java bytecode. There
at least, there's not a language rewrite happening first -- or,
rather, the rewrite is at a much lower level. (The JVM certainly
supports certain language paradigms better than others -- which can
make things weird when someone wants to do multiple inheritance [legal
in CPython] in Jython, for example.)
I think at some point, there are basic questions of why one chooses
one language over another that have to be answered. I would suggest
-- humbly ;) -- that PHP is not really chosen for its language
features. I would further suggest that it's not really chosen for its
huge library of code. I would suggest that it's actually chosen for
its accommodation of simple development patterns and its drop-dead
simple deployment paradigm. I recently wanted to write up a server-
side component to demonstrate http-only cookies. This is a few lines
of code in PHP that I just drop into any PHP server; done. I can even
mix my HTML in the same page. That is what has always been great
about PHP. Doing that in Python would have taken me some Apache
config, some sort of server script and probably a separate template
file (and then a template language) if I didn't want to print out HTML
from my wsgi app (a la CGI). Sure, I vastly prefer Python as a
language and its extensive built-in library support, but it is not
nearly as simple to develop or deploy. Well, HipHop sorta ruined the
main reason I would write something in PHP.
So, I concur with the suggestion that Brandon made in his blog and
that jproffer is making on list that this is probably of limited
attraction. Sure, if you *have* to make something perform balls-out-
fast and your developers refuse to learn a more appropriate technology
(or, in FB's case, I'd imagine they can't afford the redesign time),
this seems like a viable option. But I still think it's a hack.
Hans
That's a good read; thanks for link.
> One of the key advantages to something like HipHop is that it lets your business scale all the way up from garage startup to FaceBook with the same language, minus some slight changes. Retooling was thought to take a year or two, and would likely require new engineers and restructuring much of the pre-deployment workflow.
Yeah, that makes sense. It certainly seems reasonable that FB would
have so much legacy code and there are clearly so many third-party
tools involved here that a platform change would be *really*
expensive. Heck, it could cost them their place in the market if it
didn't work well.
... but ...
> Changing technologies (and l likely a not-insignificant percentage of your development talent) is extremely hard: not only do you have to restructure how things are built and how code is produced, but you also inevitably lose some valuable insight into the application and why it behaves as it does.
That's all fair, but I feel like the problem here is that somewhere a
long, long time ago, Facebook *must* have realized that they were
going to have scaling problems. Long before they started having a
problem, someone *must* have thought "maybe a compile-at-runtime
language isn't the right solution here". I guess to me this cross-
compiler is just a public way to admit that PHP is not the right tool
for the job, but they're stuck with all these developers that only
know PHP so it was somehow cheaper to engineer a way to change PHP to C
++ than it was to retrain developers on C++ (or, probably more
realistic, Java).
I would imagine that these developers are going to (or already had to)
learn the quirks of HipHop. We know it won't work with some things at
all and I'm sure HipHop optimizes some things far more elegantly than
others. It's a different environment that has to be learned -- and
it's an odd, indirect way to learn it.
Obviously I have 0 experience designing/developing/managing
applications that have anywhere near the amount of code/traffic/users/
populatority/vested parties/etc. as Facebook, so I can't say "this is
dumb". I'm sure this makes perfect sense for them -- and I think
they've contributed some solid work, so I'm generally eager to see how
this goes. My more-limited experience has shown, however, that when
an application really is built as a collection of isolated components,
it does indeed become far simpler to constantly review technology as a
way to address scaling. What really locks a project to a technology
is kitchen-sink, monolithic application design. This is the beauty of
the loosely coupled approach Google has taken. I'd wager that if
Google decided that the new backend for Calendar was going to be
Erlang, it probably wouldn't be all that significant a development
effort. This is obviously apples & oranges and a bit of a tangent,
but a move like HipHop almost has a its-too-big-to-fail feel about
it. Maybe that's just me.
> So to the extent it's a hack, it's a hack in the Hacker's Dictionary sense of the term: an elegant solution to a problem that solves a very large problem by changing a component in a very clever way.
Well put. Whatever I may feel about its philosophical motivations, I
agree that it's certainly very clever. :)
Hans
http://alexgaynor.net/2010/feb/02/thoughts-hiphop-php/
-Hans
> effort. This is obviously apples& oranges and a bit of a tangent,
;) Well, that's my missionary-kid upbringing, I'm sure.
> I don't know your background. I don't know your history. I know what
I've
> read over the years.
>
> What I can say is *I*, along with dozens of other technology people in
and
> out of DC, in and out of PHP, never look at our initial ideas as scaling
> ideas. We look at them as ideas and experiments to see if they have
legs.
> In
> fact, I'd go so far as to say it is counter-productive to think about
scale
> before thinking of concievability (is that a word?).
Yes, it's obvious we've been tasked with building differnet kinds of apps
over the years. I don't think I've ever had the pleasure (?) of building
an app to float out there & see if it works or catches on. There's always
been some concept of where it could grow and there's always been a need to
identify exactly what the scaling plan would be.
> Balance, my friend. Balance. Facebook (and others) start with PHP
because
> PHP is fairly ubiquitous and, like you suggest, easy as pie to drop into
> production. However, there is a point of no return where you are
committed
> to PHP and that's where HipHop comes in.
Well, that "point-of-no-return" is *exactly* my problem with HipHop. I
have had to deal with maintaining some huge codebases and that "point of no
return" is what kills a project, in my opinion. Smaller pieces, looser
coupling, is IMO a much, much better strategy for building an app that will
last.
> Personally, I wish we had HipHop when I was at b5media. We had a ton of
> scaling problems with PHP and we were running fully clustered Apache
> servers
> (25 deep, if I recall), sharded MySQL across 6ish database servers, and
we
> had massive I/O bottlenecks.
I don't see how HipHop would have helped if you had I/O bottlenecks. The
only thing it's gonna help with is CPU bottlenecks.
I also have run into big scaling problems with PHP in its traditional
hosting paradigm. This is partly why we looked to other technologies. The
epoll servers (+nginx) look like they're going to blow the socks off
anything we could tune PHP + Apache to handle. And when we needed a custom
SSL proxy server we wrote that in Java; sure we *could* have used Python,
but it wouldn't have been the right solution.
> This is, for better or for worse, the way companies get started in the
real
> world. No offense. :)
None taken. It may be the way companies get started in the real world,
but it's not necessarily the way software projects are run in the real
world. We don't start as volunteers; we start as paid software engineers.
We don't stick with tools because it's what we know, we look at benchmarks
in industry research to figure out what the right way to solve this problem
is. We do think about how things scale, about where we the decoupling
points are. I'm not just saying this because I'm naive; I'm saying it
because I've certainly been burned before and there's an important balance
to be struck between planning enough to get started and planning ahead.
Hans
> None taken. It may be the way companies get started in the real world,
> but it's not necessarily the way software projects are run in the real
> world. We don't start as volunteers; we start as paid software engineers.
> We don't stick with tools because it's what we know, we look at benchmarks
> in industry research to figure out what the right way to solve this problem
> is. We do think about how things scale, about where we the decoupling
> points are. I'm not just saying this because I'm naive; I'm saying it
> because I've certainly been burned before and there's an important balance
> to be struck between planning enough to get started and planning ahead.
>
> Hans
I think you're describing a scenario typical of large organizations with large budgets and stable, predictable use projections. Maybe that's not what all those projects were, but it sounds like the process typical of them.
That is not the environment of bootstrapped development with rapid success. Remember, the Facebook team has managed to handle all this growth successfully. There are not many organizations who can say the same given similar conditions (see Twitter or Boeing's newairplane.com), so I'm not sure criticizing them without a much better understanding of exactly how their components are put together (you can have loosely coupled PHP) is warranted.
You're also speaking as if every engineer is able to fluidly switch technologies at the drop of a hat with zero transition cost and be equally effective in the new paradigm, and that those costs can never outweigh the benefits of the shift. You also assume they have time to calmly research and plan, rather than put out the next fire while trying to do what they can to scale without running into the mythical man month problem. Human systems are a bit more squishy and hard to benchmark than engineering systems. ;)
The fact that you've been burned should tell you that software development doesn't always happen as it should, and if you've been able to have most of your projects work in the ideal way, you should be extremely thankful for your luck. :)
-Sandy
I think this is also highly dependent on your industry. I can't think of
any apps I've built or managed over the past 10 years that have been used
less than we anticipated. I can think of lots of them that ended up
getting used a lot *more* than we anticipated. And sure, we've rewritten
code, hacked things around to make them scale; we've done whatever it took.
We also learned that scaling is expensive; for us, thinking ahead is worth
it.
Here's my [final] attempt to clarify my point. I think we would all agree
that HipHop is a kludge. It's a necessary kludge for Facebook because they
committed themselves to a technology that could not scale to meet _their_
needs. I personally value cleanliness and the "right" solution. This is
often impractical, but it's still a valid opinion, I think. Given the
limitations of the system, I don't think rescuing PHP by cross-compiling it
to C++ is the "right" way to do anything (other than keep using PHP). I
think it's too bad that the Facebook web application couldn't have been
written in a way that would have made this unnecessary. While I know it's
not the same, I would again point to Google and say that their deliberate
move to start using more Java (instead of Python) feels like it's exactly
the other story -- the "right" way to evolve your technology platform.
Their point was that Python isn't always the right choice for a project
(e.g. when performance/scalability is of primary concern). I (obviously)
love Python, but I think this demonstrates Google's maturity; they deserve
credit for being flexible about their technology choices.
Hans
- M.
I am still a little puzzled by how your I/O problems were going to be
solved by HipHop ... but I suppose that point is rather peripheral to the
main points in your discussion.
Hans
On Thu, 4 Feb 2010 11:40:47 -0500, Aaron Brazell <emmen...@gmail.com>
wrote:
Great discussion, BTW.
Best to all, Ray
-----Original Message-----
From: washington-...@googlegroups.com
[mailto:washington-...@googlegroups.com] On Behalf Of Sandy
Smith
Sent: Thursday, February 04, 2010 11:56 AM
To: Washington, DC PHP Developers Group
Subject: Re: [dcphp-dev] Re: Facebook rewriting PHP?
-Sandy
--
Not much to add here except to say that it may not be a valid
conclusion to say that HIpHop means that PHP could not scale to meet
their needs. Obviously, they've gotten it to scale to this point, and
likely they can do so fairly easily by simply adding more servers
horizontally. In theory, they could do this forever but its really
expensive.
I think they're especially happy that they've gotten a near 2x
performance increase cause it sounds like they just cut their scaling
costs in half.
I wonder if they tried compiling any of their code into php
extensions. If so, the performance increases must not have been worth
the effort. Supposedly, C++ extensions were/are meant to speed up
any PHP app bottlenecks. See
http://www.sitepoint.com/blogs/2008/08/29/rasmus-lerdorf-php-frameworks-think-again/#
--
Oscar Merida
* http://OscarM.org - random thoughts on my blog
* http://SoccerBlogs.net - your daily soccer feed
* http://FutBoliviano.com - bolivian soccer, futbol de altura
I don't know where this utter myth comes from at all that PHP "isn't
scalable". It's probably one of the most scalable things you can
choose. It has healthy separation of concerns overall, and if you
wrote your app write, overcoming the problem of the actual PHP not
being fast enough is very easily solved by adding another web node.
It's also not as if it requires to this to unreasonable degrees. You
can, of course, get much better performance out of other
language/platform combinations, but there is an undeniable ease to
working with PHP. I would imagine this is why Facebook likes it. The
notion that you can easily get the same development pace from stricter
languages speaks either of inexperience with these issues, of
revanchism, or of sheer idiocy.
- M.
I probably should have clarified that by "PHP", I mean what we know as
PHP. To me PHP involves assumptions about deployment, about the dynamic
features, about the Zend engine. HipHop is not the same thing; it just is
mostly compatible with PHP syntax. (I don't consider projects like Quercus
to be the same as "PHP" either.)
> I don't know where this utter myth comes from at all that PHP "isn't
> scalable". It's probably one of the most scalable things you can
> choose. It has healthy separation of concerns overall, and if you
> wrote your app write, overcoming the problem of the actual PHP not
> being fast enough is very easily solved by adding another web node.
> It's also not as if it requires to this to unreasonable degrees. You
> can, of course, get much better performance out of other
> language/platform combinations, but there is an undeniable ease to
> working with PHP. I would imagine this is why Facebook likes it. The
> notion that you can easily get the same development pace from stricter
> languages speaks either of inexperience with these issues, of
> revanchism, or of sheer idiocy.
I never said (or certainly didn't intend to) that PHP isn't/wasn't
scalable, just that it wasn't scalable to Facebook's needs. I think that
is affirmed quite simply by the fact that they had to write a
cross-compiler.
I don't think I ever said you could get the same development paces from
other languages (though, certainly, claiming that PHP is the most
productive language is very subjective -- and to me, wrong). You have to
factor in the time it took for them to write their cross-compiler into the
equation here. *That*, I think, is a critical part of discussing which was
the most efficient choice here.
Hans
Yeah, I agree. I'm talking about something different (and probably more
ideal than I can even really claim).
> That is not the environment of bootstrapped development with rapid
> success. Remember, the Facebook team has managed to handle all this
growth
> successfully. There are not many organizations who can say the same
given
> similar conditions (see Twitter or Boeing's newairplane.com), so I'm not
> sure criticizing them without a much better understanding of exactly how
> their components are put together (you can have loosely coupled PHP) is
> warranted.
Yeah, that's certainly fair. I'm sure they're an extremely smart group.
I think my suggested criticism is more a criticism of design choices that I
have witnessed (and often that I have been a part of making), which is
obviously in a different environment. Other than using Facebook and having
looked at some of their other, non-PHP open-source projects, I really don't
have any insight into their application. For me Facebook loads fast enough
and while on the surface it feels like a monolithic webapp, I do know that
they have different technologies driving different components.
> You're also speaking as if every engineer is able to fluidly switch
> technologies at the drop of a hat with zero transition cost and be
equally
> effective in the new paradigm, and that those costs can never outweigh
the
> benefits of the shift. You also assume they have time to calmly research
> and plan, rather than put out the next fire while trying to do what they
> can to scale without running into the mythical man month problem. Human
> systems are a bit more squishy and hard to benchmark than engineering
> systems. ;)
Well, that's all true. I'm not able to fluidly switch paradigms; there
are certainly context switching costs at a minimum. It would have been
expensive for Facebook to teach their employees to develop for a new
language/platform. I concur that this was a good strategy for them to
increase their performance. I think my original point, which I'm now
starting to forget, was just that they must have been planning for success
a lot earlier than they ultimately proved to be successful.
> The fact that you've been burned should tell you that software
development
> doesn't always happen as it should, and if you've been able to have most
of
> your projects work in the ideal way, you should be extremely thankful
for
> your luck. :)
Yes, that's fair. And I'm sure I have selective memory :) -- Not
everything has ever gone right, but I think that there's merit to planning
ahead, to reconsidering technology choices. Sometimes you do have to
"throw one away", that's part of an evolving product. I think it's hard
for a company to do that; it's certainly hard for me to look back on
something I wrote and say "you know, that wasn't a good idea", but I think
that's important. I see HipHop as an example of desperately trying *not*
to "throw one away".
Hans
That being said, I question there being a trade-off at all. There is
one project I am working on right now where PHP is the actual
bottleneck, and not the database, I/O, the network, RAM, et cetera.
This was a hard situation to get into accidentally, and it's mainly
because we're doing a fair deal of math in PHP. I don't have the
manhours available right now to move that into C extensions, so that
in that sense hiphop will actually help me. But, back to my point, for
the other projects, and trust me, I'm working with some serious weight
in iron here, PHP was always the lesser problem. It's really easily to
write PHP code that runs slow, but it's also equally easy to write PHP
code, and build a stack that, runs really, really fast. It's largely a
question of competence. Miserable execution speeds of 30 requests per
second from a box aren't unheard of; but it's equally common to get
that to 1,000 requests a second with some optimization effort, or to
much higher numbers.
The truth of it is that most of the heavy lifting of complicated web
apps happens outside the frontend layer, and the frontend layer is
rarely heavily stressed.
Good points. That's certainly true that FB worked fine before. I just
assume that the effort of rewriting the PHP engine was a significant effort
and that they wouldn't have funded it if it weren't important to them. So
maybe *need* is the wrong word, but clearly it was worth a lot to them.
And I assumed that they've been putting it into production because they
felt PHP without it wasn't good enough (or cheap enough) for their needs.
I suppose this is somewhat of a semantic game.
Yeah, it does sound like HipHop will help you in the case you describe.
And I certainly concur that being CPU-bound is a pretty rare thing in web
applications. Most of my challenges with PHP & scaling have had more to do
with the serving platform (Apache, mod_php, etc.) than PHP itself.
I don't think we're arguing about anything :)
Hans
On Thu, 4 Feb 2010 13:12:39 -0500, Marcel Esser <marcel...@gmail.com>
wrote:
Actually, I was a bit misinformed on that one. As an amendment to that
statement. It turns out that it was under development for the past year, in
production use the last 6 months or so.
In terms of site performance, poke around with YSlow and/or some of the API's
and you'll find where the problems are. The vast majority of it is at the
browser level with rendering and the requests themselves.
kc
--
D. Keith Casey, Jr.
CEO, CaseySoftware, LLC
http://CaseySoftware.com
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en
Let me be the first to plow a new field.
The CakePHP team has some weird stuff going on right now... it looks like
CakeDC was taking the reigns in terms of running things, doing training, and
generally commercializing things. In terms of the team itself, Nate Abele,
Joel Perras, and the project lead (don't remember his name) all split and
started a new project called Lithium.
I'm not speaking ill of the project... just seems like some stuff is odd.
I read that you can use accelerators to help speed it up, and there
are some tweaking tips, but like someone else said, CodeIgniter
usually performs better out of the box. I'm starting to see some CI on
some decently-large sites, too, with pretty good performance.
The difference in syntax between cake and CI is negligible - I don't
really see any benefits to Cake.
I'm an MK as well, but I'm reserving judgment on this whole thing so I
can later claim I was on the "winning" side the whole time. :)
echo 'Why MVC should be used at first place? Some really key benefits are: ' . $answer1;
# single point of entry or SEO, at least not important for me
echo 'How learning involved is worth adapting any MVC (say CakePHP): ' . $answer2;
# Authentication or DB_connection or whatever - one can perhaps do faster directly than learning new culture/tricks/style.
echo 'Will one be hostage to MVC provider till life of web project? They upgrade you upgrade: ' . $answer3;
# I remember phpbb upgrade issues
echo 'Code maintenance (by different developer down the road) - would that be easier? ' . $answer4;
# I tried to fix/enhance code in MVC framework of predecessor - couple of years ago though
echo 'Is MVC framed Code easy to understand? ' . $answer5;
E_FATAL
You have to name your class. ;)
> echo 'Why MVC should be used at first place? Some really key benefits are: ' . $answer1;
> # single point of entry or SEO, at least not important for me
$answer1 = <<< EOF
Technically, single-point-of-entry and MVC are not the same thing,
though typically in PHP they go hand-in-hand (in that MVC kinda requires
a single-point-of-entry). Front controllers in PHP tend to be a
discussion topic (and debate) in and of themselves since PHP's natural
deployment paradigm is not to use a single entry point -- so you have to
do something that feels a little unnatural in PHP to get there.
See http://www.phppatterns.com/docs/design/the_front_controller_and_php
for more on front controllers in PHP.
For me, the front controller is important in PHP frameworks because
there is going to be a lot of boilerplate setup/framework code that is
going to be identical for every request. Even "framework-free" PHP apps
will some sort of "require 'init.php';" at the top of the script to
initialize the environment. A front controller, though, makes it
possible to have a *single* request/response pipeline. Now all your
framework setup, request filtering, response rendering logic, and error
handling can happen in *one* place (well, at least the errors you can
catch/handle). So that "one place" is the key reason [that I would] use
a front controller: DRY.
MVC is just an organization paradigm. Once you've got your single
request/response system, you are probably itching to think about how to
efficiently organize your application code. Typically that's where some
form of "MVC" comes in. Different frameworks tend to disagree on
exactly where the lines get drawn between those different letters. Some
frameworks have different acronyms, but the basic idea is separation of
concerns.
EOF;
> echo 'How learning involved is worth adapting any MVC (say CakePHP): ' . $answer2;
> # Authentication or DB_connection or whatever - one can perhaps do faster directly than learning new culture/tricks/style.
$answer2 = <<< EOF
Um, sure it's often faster to just hack something together rather than
think about it. Where frameworks save time is when you reuse
components. For example, maybe you come to discover that the code
needed to "edit user" has a lot of duplication with the code needed to
"save user" -- perhaps they both have to parse and filter request data,
potentially query database for an existing user. So, for example,
having a SaveUserAction extend a EditUserAction would probably be an
effective way to reuse all that initialization code. Or what if you
decide that you'd like to be able to return your list of articles as an
RSS feed instead of an HTML template? The strength of frameworks is
that they [can] greatly lessen the amount of code needed to add new
features; simplify maintainability; and (by virtue of fewer code paths)
make it easier to debug, test and secure your application.
EOF;
> echo 'Is MVC framed Code easy to understand? ' . $answer5;
# Yes? I have no idea. "Are books easy to understand?"
# It may depend on the author?
Hans
--
You received this message because you are subscribed to the Google
Group: "Washington, DC PHP Developers Group" - http://www.dcphp.net
To post, send email to washington-...@googlegroups.com
To unsubscribe, send email to washington-dcphp-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/washington-dcphp-group?hl=en