Would it make sense to switch to HipHop instead of XCache?
Is HipHop ready for primetime or should we wait several months before implementing it?
Edit: we are interesting in testing the configuration on a server running vBulletin.
Let me clear up a misconception you might have about Hiphop and Xcache. XCache works by adding Opcode caching to ZEND's PHP implementation (like APC and friends), while Facebook's HipHop allows for PHP code to be transformed into C++ code and then compiled using g++. It's not possible to run XCache with HipHop as HipHop doesn't depend on Zend interpreter (and doesn't even use php opcodes as it's compiled to bytecode after transformed to C++).
Now to answer your question, HipHop is being used live to host a large amount of Facebook's traffic. Facebook wouldn't release this project if it wasn't near stable, but since it is very new I would still exercise caution. HipHop is not just a patch to the old Zend Interpreter, it is a completely different way to run the PHP code and will probably have a few bugs in it.
One thing that Facebook did to ensure that Hiphop was working before they switched to it was they were able to setup very rigorous unit tests of each possible request on their site. That way if the output from Hiphop was different from the normal Zend PHP, they would go back and debug some more until everything "worked for them". Just because it "works" on Facebook code base doesn't prove that it'll work for yours. If you do decide to switch to HipHop, make sure to test it well.
EDIT:
HHVM (new VM version of HPHP) can now eval and create_function. They should be the same for all/most meaningful reasons.
There are a few things that aren't compatible with HipHop. They removed the eval and create_function functions. They also only support PHP 5.2.x for now, but they are plan to add support for 5.3 "soon".
I like the idea of HipHop, so don't get me wrong here, but there is something to remember: HipHop is not for everyone. From Sebastian Bergmann:
it is not a solution for a problem faced by 99.9% of the PHP deployments out there
Unless you have Facebook proportion traffic and your bottleneck is CPU or memory usage, you're not likely to see much of a benefit (as compared to xcache, apc, etc). Database and file system access are still going to be your killers.
I'm fairly confident that vbulletin 3.x will not work with HipHop. VB 3's plugin system consists of nearly 2000 eval statements sprinkled throughout the code, and eval is not supported by hiphop.
That's probably only the tip of the iceberg, when it comes to getting vbulletin to compile.
Related
I've been reading about Facebook's Hack which lead me to reading about HipHop Virtual Machine. I wanted a better understanding of this and could not find a clear definition. Wikipedia defines it as: HipHop for PHP (shortened as HipHop) describes a series of PHP execution engines and improvements created by Facebook. I don't understand what PHP engines are...
So I guess then my question is: What exactly are "PHP execution engines?" and how exactly do the benefit PHP applications?
Thanks!
You can run your PHP code with the standard (Zend) engine that you download from php.net, that works great. If you download WAMP, MAMP, or any of the other pre-packaged PHP & MySQL for your Operating system packages, this is what you're getting.
Alternately you can run (most of[1]) your PHP code with HipHop, that works great.
Which one you're using should be effectively invisible to your end users. Your developers, and operations teams will need to know.
You may choose to use HipHop if you're running a site that gets a lot of traffic. HipHop while not supporting all of the features of PHP, does run a bunch faster. It also has some new features not available in the main PHP distribution mostly to do with type hinting. These can provide some pretty attractive tools to read through your code checking for bugs.
Reasons you may want to use HipHop:
Performance is a big deal for you
The static analysis tools available with HipHop have serious worth to your team
The new features in HipHop but not in Zend PHP are attractive to your team.
Reasons you may want to use Zend PHP
You need an extension not available for HipHop (there's lots of extensions out there, think: gd, curl, imagemagik, etc. Many are available for HipHop now, many aren't).
Your code, or framework is making use of unsupported features.
You have a lot of expertise in hosting your current Webserver & PHP stack, and don't want to start from scratch.
This post goes into some HHVM vs HACK differences, and gives a nice run down: http://www.marco.org/2014/03/21/hack
[1] Not all code that you can run with the regular PHP engine currently works on HipHop. They're working on most of the issues, some they've just decided not to fix (I think variable variables may be an example of this e.g. $$var)
Can any one here provide me a good tutorial on compiling PHP using HipHop? i saw this link . But i cannot understand the linux commands. I developed the application in windows. I was not able to run those commands in linux
$HPHP_HOME/src/hphp/hphp test.php
This command gave me error bash command not found.
in the source i got, i do not have anything named hphp inside the folder hphp, is that a method inside main.cpp???
Can any one here provide me a good tutorial on compiling PHP using HipHop? [...] i cannot understand the linux commands.
HipHop and the companion/successor HHVM, are for advanced users that are trying to resolve specific performance edge cases. Normal PHP developers will not ever benefit from any of the things that HipHop provides. In fact, in many cases, you can get just as much of a performance benefit through simple performance profiling and targeted optimizations combined with a bytecode cache, like APC.
If you do not understand the commands needed to get it running, you do not fall into the class of user that should attempt to use it. Break out your profiling tools instead, as they will be far, far more valuable to you.
It's been clarified that the actual intent is to use HipHop as a PHP code protection mechanism. That's an even worse idea!
HipHop is designed to run as an application server. That is, it contains a web server.
HipHop binaries are huge, often greater than 500 MB. They are not appropriate for redistribution.
HipHop memory use is significantly larger than the binary.
HipHop is designed and intended to run on machines dedicated to the task.
It's not intended for that purpose... and everything can be decompiled. That includes the commercial products that are designed for the task, ionCube and Zend Guard. All it takes is a bit of time or money, and your source is mine. Your best defense against intellectual property theft is a good license and a good lawyer, not a technological solution that makes it harder to run your code.
I wrote an application in PHP using the Symfony Framework. Now that the traffic to my site is growing, I really need to recompile it with HipHop PHP.
Is it possible to do it? After recompiling it, do I need to use fastcgi module to run it?
I don't wish to sound pretentious but are you really going to have a site the size of facebook? Majority of large websites don't use HipHop. They just use efficient caching (Varnish for example), good database optimisation(indexes in the right places etc.), and code accelerators(such as APC) I don't think you will really notice much of a difference if you did decide to use HipHop. Bare in mind that a lot of PHP functions don't work in HipHop also.
If you're using Symfony2, have you looked into ESI (Edge Side Includes)?
Just my thoughts, but really I don't think it'll be worth the headache to use HipHop.
As far as I know, HipHop only supports PHP <= 5.2, so if you're planning on using any PHP 5.3 features you'll need to figure out something else. I don't see why it wouldn't support any framework though, provided it's PHP 5.2-compatible.
Yesterday Facebook launched HipHop, a sourcecode-converter from php to c++. The set of php functions and constructions is more limited than in standard php.
Are the current popular php frameworks (ZF, CakePHP, symfony) compatible with HipHop? If not, which parts of these frameworks are not usable?
If I'm not mistaken, HipHop has not been released yet -- even the wiki page linked from the Facebook annoucement yesterday is not up yet.
So, it's going to be a bit hard to answer, right now.
I suppose it'll all depend on :
The features used by the Frameworks -- like already said here and there, stuff like eval is not supported by HipHop
The PHP extensions used by the Frameworks : only a couple of those have been ported by Facebook to HipHop.
Depending on the Frameworks and your specific needs, maybe/probably some subsets of the Frameworks you are using will be supported, even if not every available components... I suppose time will tell which ;-)
With at least ZF and Symfony being used for Enterprise level applications, chances are pretty good they will run with HipHop. If not now, then sooner or later. However, the question is not so much if they can run with these frameworks, but how your supporting IT architecture looks like.
HipHop is for scaling large multiserver high traffic sites like Facebook. In your regular web application, you will likely get no advantage out of it. Just continue to use memcache and APC.
See these related articles:
http://www.readwriteweb.com/archives/rasmus-lerdorf-php-hiphop-facebook.php
http://ilia.ws/archives/213-My-Thoughts-on-HipHop.html
http://terrychay.com/article/hiphop-for-faster-php.shtml
http://www.brandonsavage.net/hiphop-for-php-who-benefits-who-doesnt/
While I'm sure most of us are curious about what HipHop is going to be, I know it will not be a replacement for PHP - it's very much a niche product: unless you're running a large server farm then the performance benefits vs the maintenance costs just wouldn't justify it.
Perhaps it might be an interesting alternative to use encoded PHP for some people - but again this introduces even greater maintenance overheads. The only low-volume scenario where a compiled PHP would seem to make a lot of sense is for embedded devices (where the software exists to support the hardware and not vice versa) and for very high security installations (where its not a good idea to have a interpreter available).
It's far to early to be able to say what PHP software will work with it. However even once thats established, I'd want to see a solid commitment from any supplier that they were going to explicitly support HipHop in the future before I switched.
C.
I won't repeat what has already been said, I'll just add that as soon as HipHop is released you can count on the opensource community to submit patches for your favorite framework for increased compatibility with HipHop.
Also, one good way to test whether your favorite framework is compatible or not would be to launch the test suite using HPHPi (you then know where to concentrate your patching effort ;).
Searching for 'eval' gives a lot of false positives, as you get hits for the word "evaluate" in comments, or escapeValue if the search isn't case sensitive, etc.
If you search for 'eval(' in ZF 1.11 you'll find in once in Zend/Serializer/Adapter/PhpCode.php on line 59, in a method that unserializes stored PHP code. The method isn't a part of the MVC architecture, db component, and actually isn't used anywhere else in the framework (Zend_Serializer_Adapter_PhpCode isn't instantiated anywhere else in the code base).
So if eval breaks your ZF-Hip Hop app, don't use Zend_Serializer_Adapter_PhpCode, or eval in your consumer code.
Simple answer: I don't think it would.
Just saw this on hiphop page: https://github.com/facebook/hiphop-php/wiki/
"You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance."
Did a search for 'eval' on ZF 1.9 and there are over 100 occurrences.
If I write a hello world app using a PHP web framework such as CodeIgniter and then I compile it and run it using HipHop. Will it run faster than if I write the same hello world app in django or rails?
HIPHOP converts php code into C++ code, which needs to be compiled to run. Since pre-compiled code runs faster and uses less memory then scriping languages like python/php it will probably run faster in the example you have given.
However, HIPHOP does not convert all code. A lot of code in php is dynamic and can not be changed to c++, this means you will have to write your code with this in mind. If codeigniter can even be compiled using HIPHOP is another question.
Terry Chay wrote a big article about HIPHOP, covering when to use it, it's limitations and future. I would recomment reading this, as it will most likely answer most of your questions and give you some insight into how it works :)
http://terrychay.com/article/hiphop-for-faster-php.shtml
At that point the run time is inconsequential. HipHop was designed for scaling... meaning billions of requests. There's absolutely no need to use something like HipHop for even a medium size website.
But more to the point of your question... I don't think there have been comparison charts available for us to see, but I doubt the run time would be faster at that level.
i don't know about django or rails, so this is a bit off-topic.
with plain php, the request goes to apache, then to mod_php. mod_php loads the helloworld.php script from disk, parses & tokenizes it, compiles it to bytecode, then interprets the bytecode, passes the output back to apache, apache serves it to the user.
with php and an optimizer the first run is about the same as with plain php, but the compiled source code is stored in ram. then, for the second request: goes to apache, apache to mod_php, apc loads bytecode from ram, interprets it, passes it back to apache, back to the user.
with hiphop there is no apache, but hiphop itself and there's no interpreter, so request goes directly to hiphop and back to the user. so yes, it's faster, because of several reasons:
faster startup because there's no bytecode compilation needed - the program is already in machine-readable code. so no per-request compilation and no source file reading.
no interpreter. machine code is not necessarily faster - that depends on the quality of source translation (hiphop) and the quality of the static compiler (g++). hiphop translated code is not fast compared to hand-written c code, because there's a bit of overhead because of type handling and such.
with node.js, there's also no apache. the script is started and directly compiled to machine code (because the V8 compiler does that), so it's kind of AOT (ahead of time) compiling (or is it still called JIT? i don't really know). every request is then directly handled by the already compiled machine code; so node.js is actually very comparable to hiphop. i assume hiphop to be multithreaded or something like this, while node does evented IO.
facebook claims a 50% speed gain, which is not really that much; if you compare the results of the language shootout, you'll see for the execution speed of assorted algorithms, php is 5 to 250 times slower.
so why only 50%? because ...
web apps depend on much more than just execution speed, e.g. IO
php's type system prevents hiphop to make the best use of c++'s static types
in practice, a lot of php is already C, because most of the functionality is either built in or comes from extensions. extensions are programmed in C and statically compiled.
i'm not sure if there was a huge performance gain for hello world, because hello world, even with a good framework, is still so small execution speed could be negligible in comparison to all the other overhead (network latency and stuff).
imo: if you want speed and ease of use, go for node.js :)
Running a simple application is always faster in any language. When it's become as complex as facebook, then you will face numerous of problems. PHP slowness will be show it's face. In same times, converting existing code to another language is not an options, since all logic and code is not so easy to translated to other language's syntax. That's why facebook developer decide to keep the old code, and make PHP faster. That's the reason they create their own PHP compiler, called HipHop.
Read this story from the perspective one of Facebook developer, so you know the history of HipHop.
That is not really an apple to apples comparison. In the most level playing field you might have something like:
Django running behind apache
Django rendering an HTML template to say hello world (no caching)
AND
HPHP running behind apache
HPHP rendring an HTML template to say hello world (again, no caching)
There is no database, almost no file I/O, and no caching. If you hit the page 10,000 times with a load generator at varying concurrency levels you will probably find that HPHP will outperform Django or rails - that is to say it can serve render more pages per second and keep up with your traffic a bit better.
The question is, will you ever have this many concurrent users? If you will, will they likely be hitting a database or a cached page?
HPHP sounds cool, but IMHO there is no reason to jump ship just yet (unless you are getting lots of traffic, in which case it might make sense to check it out).
Will it run faster than if I write the
same hello world app in django or
rails?
It probably will, but don't fret. If we're talking prospective speed improvements from yet unreleased projects, Pythonistas have pypy-jit and unladen-swallow to look forward to ;)