I wish to run PHP and Erlang on a web server. Apache is ruled out, because the backend Erlang process would need to handle around 3000 requests concurrently. So definitely something with a smaller memory footprint like lighttpd...
Which one would you recommend? And why?
Erlang has built-in web server:
http://yaws.hyber.org/
Which you can use. It is supposed to be really really fast.
If you want to expose Erlang to the web, Yaws is the way to go (in just learning Erlang, so this may be incorrect)
edit:
After digging around a bit, I found that the Erlang webserver (Yaws) CAN run PHP scripts. So your answer is an Erlang webserver!
http://yaws.hyber.org/cgi.yaws
Its hard to answer this one without more information. What is it you wish to use erlang and php for? Is php your frontend for a backend erlang process? Or is erlang going to do some of the frontend also?
I've seen folks do well with nginx in front of erlang and fastcgi. You could run the php through fastcgi with nginx doing the forwarding. Without more information it would be hard to say more than that.
Run your php frontend with anything you like (apache i hope) and communicate with your erlang as a backend.
Read:
http://www.erlang-factory.com/upload/presentations/117/Todd-Lipcon-ErlangFactoryLondon2009-BuildingMulti-LanguageWebArchitecturesusingErlangandThrift.pdf
Basically talks how to run a php frontend, because it is good at strings and template designers 'get it' with a erlang backend because it is good at concurrency, etc. Then he glue it all together with thrifty
best quote
Where PHP sucks is where Erlang
excels!
I And vice versa!
Related
Per this post here there are 3 ways
(1)do the whole thing in C++, making your program a standalone web server (possibly proxying through apache to provide things like ssl, static media, authentication etc.)
(2)run C++ in a cgi-bin, through apache
make a PHP wrapper that shells out to the C++ part (this is a nice option if the performance-critical part is small, as you can still use the comfort that PHP's garbage collection and string manipulation gives you)
I'm not sure which is best so I looked at what a high volume site does. Here is a post from Facebook in 2010
They use a static analysis tool Hip Hop, to convert PHP to C++.
I don't need the static analysis tool as I only have about 1500 lines and can convert by hand...but I need a starting point.
Right now I run a Lamp stack and want to stay on it minus the (P)HP.
Here is a link that explains how Facebook works. Not sure how accurate it is.
Thanks
As the comments note, Facebook is almost certainly using a highly-customized solution that involves high administration costs in return for very high efficiency. It is unlikely that this is actually what you want.
Since what you want is simply to replace the "P" in your LAMP stack, that implies that you probably want to keep the "LAM" -- the Linux, Apache, and MySQL (if relevant) parts. That's a good idea; while there are advantages at Facebook's scale to running a custom web server, it is extremely unlikely that it will actually be useful for you, and continuing to run Apache is certainly much easier and simpler. (And probably more secure, since you don't have to think about the security and fix bugs all by yourself.)
And you're planning to translate all your PHP, not just part of it, so calling C++ from PHP doesn't make sense.
Thus, in your case, the best solution is most likely to be running the C++ application via cgi-bin with your existing Apache server.
FastCGI is a much better option than CGI, and can act like CGI in certain circumstances. If you only want to work with Apache, you can also develop an Apache module, and there's an excellent book on the subject: The Apache Modules Book This describes many elements of C development with Apache acting in many ways like a (sort of) application server.
With careful C/C++ coding, you can achieve remarkable performance with limited memory. Not for everything, but in some circumstances, very powerful.
I have a C# application that needs to call a PHP script, and get the output, in the fastest possible way. The options I explored:
Executing the script with PHP CLI (Pro: Easy / Cons: No Opcode Cache / Precompilation ]
Compiling the PHP (Phalanger, Hiphop, etc.) [Pro: No Webserver / Con: Compatibility ]
Using an embedded webserver (AppWeb, Cherokee, Lighttpd) [Pro: Simple / Cons: Deployment ]
Are there any other options left?
EDIT: The best possible option would be to make use of the build-in FastCGI server of PHP, by running php-cgi.exe -b 127.0.0.1. But there seems no (C#) code to talk to a server available. While there are so many server-side libraries (like FCGIDotNet and SharpCGI), they all implement the server-side of the protocol.
One other option could be to run the PHP CLI script as a daemon (good blog post on this here).
If the script has a particularly long startup/cleanup, then running it as a daemon would mean that you only do this once.
The downside is that you'd need to write a way of communicating with that daemon, to get the data from C# to it. You'd also need to keep an eye out on its memory usage over time.
The best method is always going to be specific to your script though.
As you may know, PHP originally stood for "Personal Home Page", it is now said to stand for "PHP: Hypertext Preprocessor", which literally states it's usage, and basically is not something that a developer would embed into his application just to have a scripting option.
Unless you have some really specific piece of software and strong arguments, I'd suggest you to stick to Lua, or similar scripting libraries which are easy to embed and maintain. Otherwise, use it the way as everyone is using it, CLI. Or else be prepared to face the consequences.
I'm in the process of setting up a webserver from scratch, mainly for writing webapps with Python. On looking at alternatives to Apache+mod_wsgi, it appears that pypy plays very nicely indeed with pretty much everything I intend to use for my own apps. Not really having had a chance to play with PyPy properly, I feel this is a great opportunity to get to use it, since I don't need the server to be bulletproof.
However, there are some PHP apps that I would like to run on the webserver for administrative purposes (PHPPgAdmin, for example). Is there an elegant solution that allows me to use PyPy within a PHP-compatible webserver like Apache? Or am I going to have to run CherryPy/Paste or one of the other WSGI servers, with Apache and mod_wsgi on a separate port to provide administrative services?
You can run your PyPy apps behind mod_proxy and serve static content with Apache (or even better use nginx). In addition to CherryPy, gunicorn and tornado run great on PyPy.
I know that mod_wsgi doesn't work with mod_php
I heavily advise you, running PHP and Python applications on CGI level.
PHP 5.x runs on CGI, for python there exists flup, that makes it possible to run WSGI Applications on CGI.
Tamer
I'm building a PHP web application and I've reached a point that I need to build a Comet server because I need to update my users' whenever a new data is available (pretty much like FB). I've spent so much time searching the web and I've come to a conclusion that the best way to build Comet server is to build it with erlang. Also I've found that apache-php is not a good combination for doing that because the process per request issue.So, I have to build a lightweight http server for comet application.
I'm totally newbie in erlang world but I'm thinking of implementing Comet server in erlang and make it to function as interface for updating the clients only. For the rest of my web application functions, I still want to continue implementing them with PHP. So directing the requests of updating the clients to the erlang server and directing the other requests to apache-php server.
It seems very complicating. I need to know what's the best way to learn erlang for the sake of building Comet server and how to combine the two languages (erlang and php) to work together like when I have new info. to be pushed to the clients, I need to make the new changes available to Comet and then it pushes the info to the users. So how can I benefit from php and erlang and make them work together.
Sorry for the long explanation but I really need your help guys and any guidance you may give me to learn and implement what I want. Thanks a lot in advance.
EDIT:
Should I consider learning Python and Twisted to accomplish what I want?
It's definitely possible to do this with Erlang. One possibility would be to use long polling, which you can do with mochiweb. http://code.google.com/p/mochiweb/
Another idea is to use sockets. Until web sockets are supported by a reasonable number of browsers, you'll have to use a flash "bridge" to create a TCP connection, and use javascript to communicate with the server. Take a look at web socket JS: http://github.com/gimite/web-socket-js
Once you have this set up, you can communicate between your Erlang processes and PHP with something like this: http://www.math-hat.com/~zukerman/projects/php-erlang/
Then again, if you're still a newbie to Erlang, maybe you'll save time in the long run with Python and Twisted or Tornado.
Apache+php is indeed a bad technology for comet style applications. You can use a lot of other technologies that are closer to php though: Ruby, Python and Perl should all be usable. If you really want, you could probably write some kind of socket server in php aswell, but I would probably not bet on getting it to work out. That's not to say that Erlang isn't a good choice, but there are more mainstream alternatives.
If you don't want to use a mainstream language, be sure also to check out node.js, which runs some very impressive benchmarks. Plus you may already know a bit of javascript.
You can learn Erlang pretty quickly, you should be able to use things like gen_server, gen_event and that sort of thing from OTP. The quickest way to learn Erlang should be to work your way through the documentation and examples at: http://www.erlang.org/doc/index.html.
For the communication between PHP and Erlang you can use sockets, fsockopen() and the rest on the PHP side and gen_tcp on the Erlang side. You can parse the Erlang terms sent trough the pipe from the PHP side (more info here).
I never used Erlang and PHP but I used Erlang and Python with some success, knowing PHP it should be pretty easy, just try to keep everything clean and keep the state on the Erlang side, using PHP only to generate the UI.
If you are considering Python and Twisted you can take a look at Orbited. They have very mature Comet implementation. You can make Orbited to communicate with your PHP application through STOMP protocol.
This article has a decent tutorial which will get you started with Orbited
http://thingsilearned.com/2009/06/09/starting-out-with-comet-orbited-part-1/
To integrate your application with PHP you will need to google for PHP STOMP clients
An addtional option is to use Nginx and it's push module (http://pushmodule.slact.net/)
This will allow you to use Comet from PHP without the need to learn a new language.
You should look into Yaws. It's an Erlang web server that's been around for over a decade, is extremely stable and still under active development and maintenance, and supports long-polling, PHP applications, WebSockets, and much much more — pretty much everything you could want.
The Yaws sources are on github and its mailing list is here.
Try Chicago Boss framework here ... using that you don't have to know the nuts and bolts of the thing called OTP (which actually very easy, powerful and battle proved), because the designer of Chicago Boss, managed to encapsulate it nicely... according to the tutorial.
I'm learning it right now, after learning OTP.
I'm developing a web app for an Apache shared hosting server. I have already written some code in Perl but I recently found out, to my surprise, the shared hosting provider does not provided mod_perl or a way to install it.
I have been a bit worried that running a Perl web app through CGI without mod_perl would make it very slow? Should I switch all of my code to PHP instead, would that be faster?
The reason I chose Perl in the first place is, I'm very familiar with Perl more than PHP. Also I wanted to be able to use my Perl libraries outside the realm of web development.
So if any of you are experienced with Apache web development, can you shed some light as to which direction should I take.
For the sake of this question, lets say the web application will get 500+ hits a day.
Which would be faster PHP or Perl without mod_perl?
Thanks in advance for the help.
At only 500 hits a day, you could write your code in just about anything and not have to worry about slow downs. 500 hits a day evens out to about 1 page every 3 minutes. Even assuming a non-normal distribution of hits, you shouldn't really worry about this with such small traffic numbers.
PHP would be faster.
However, with only 500 hits per day, using cgi would not be a problem. Not even with 500 hits an hour.
Much depends on your architecture. Modern Perl frameworks aren't well suited for use as CGI (long start-up times). If you use CGI, Catalyst probably is a bad idea. That said, using classical architecture it should be quite manageable.
Unless your shared host is running PHP as a CGI application (not mod_php or FastCGI), PHP is almost1 always going to be faster. While Perl, running as a CGI, could probably handle your 500 hits a day, an application/page developed with CGI is going to be sluggish.
CGI works by spawning a new process to run your program for each request. Both mod_php and FastCGI applications mitigate this by spawning a set a number of processes and then using these to run your application. In other words, a new processes isn't being spawned for each request. (This is an oversimplified explanation, please don't use in a CS Term Paper. See mod_php and FastCGI docs for more info)
You could come up with pathological examples where it wouldn't be, but then you'd be the kind of person to come up with pathological examples of things, and no one wants that
Speed shouldn't be your concern. Both languages are suitable for web applications.
For the volume of traffic you're looking at, Perl with vanilla CGI shouldn't be an issue, although I would second the earlier recommendations to check out FastCGI as another option which your hosting service may provide.
Or another option would be to look for a different hosting company...
Expanding on what Alan Storm said, you might be able to use Perl with FCGI instead.
FCGI works by having a sort of stand-alone server, a daemon if you like, that connects with your web server via FCGI protocol and delegates/dispatches requests.
This is faster than normal CGI, as this emulates a sort of "servlet" model, the application is persistent, and there is no need for a new initialization on every call like there is with normal CGI.
I have not yet learned how to do this myself, but I believe Catalyst has this option, so its just a matter of learning how to replicate this.
FastCGI/FCGI should be available on drastically more hosts than plain old mod_perl, as FCGI applications are not web-server specific, and some web servers implement PHP via a fcgi utility.
And I've experimented with FCGI webserving a little, and preliminary tests say it can handle at least 500 req/s , far faster than the above concerns of 500/day or 500/hour.
It's possible to hack fastcgi support into a hosting account that doesn't support it. I compiled the fastcgi library with the install prefix set to the same thing as the home directory on the hosting account. Then I synced it up and set up catalyst to use the small cgi-fcgi bridge. It worked well. Nice and fast, because the cgi bridge is just a tiny little executable. The catalyst process persisted in the background just fine.
The answer in everyones mind is: who cares.
500 requests per day is nothing.
Just use whats fastest to implement / maintain and move on.
For lighter web frameworks that will work using CGI then have a look at....
Squatting
CGI::Application
CGI::Lazy
It depends mostly on how complex your code is and how it's put together; if you run it as CGI, perl will compile your script and modules on each invocation, and will have to reconnect to your database for each request. If your code is complex enough, this may take a few seconds per pageview, which may hamper user experience.
If your codebase and used modules isn't huge though, there should be no problem at all.
You can do a perl -c on your code to get a feel for how long perl startup and your compilation time is.