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
Related
I am having one enterprise application developed using j2ee technology. I also have some php application. I want to merge the php application in my enterprise application to enhance the functionality without rewriting the code in j2ee. Could anyone please suggest me how to do this. I did some research on this and found following options
PHP & Java bridge - In this I will run tomcat behind apache server. The php module will be in apache and j2ee app in tomcat. This seems to be the opposite of how I would want my app to run. As the user registers in j2ee app and will also use the module build in php. So I would want my tomcat server to be oin front.
Install php on tomcat and run the php module in tomcat server. I tried many times to configure this with PHP5+ and tomcat6+ but not able to do that. I also could not find proper php & tomcat version combination which works together.
Please help me to find the best option (open for any new options as well) keeping application performance in mind.
running the PHP part on Apache httpd and the java part on Tomcat "behind" it is not that wrong. The fact that Tomcat is behind apache server is only a matter of connection flow, but from a user POV /forum/page.php will be handled by PHP, while /supercomputation/dothat will be handled by java.
The only problem is how you put the two together on the same page, if you need to, cause in this case only server side includes, iframes or javascript pop on my mind.
Another approach is to install PHP on a separate server, even another httpd on a different port, eventually listening only on 127.0.0.1, and then use a java server side component to "fetch" PHP output and merge it in the page generated by tomcat.
It might sound a hack, but it's not that hard at all, is already supported by many frameworks, and I've seen enormous web sites in production with a java based "frontend" that aggregated contents coming from other PHP and Python subsystems.
Whatever solution you decide to adopt, you'll need to setup some coordination between the two systems ... for example, single authentication for users. How to do that heavily depends on how those applications are designed, and will probably need some tuning here and there.
Basically I'm looking for a way to get rid of my PHP dependence, and I would like to switch to Python. I'm having trouble finding a way to basically make python a drop in replacement. I'm familiar with Django but its just not quick and dirty enough for most small things I have to do. So I'm wondering if there is an Apache module or a way to setup mod_wsgi to serve up *.py files the same way mod_php serves up *.php from the server root?
Note: I have found the various python extensions to php for calling code from PHP but that doesn't really solve the curly brace hell.
The files that mod_wsgi calls are Python files. Additionally, if you set them up in daemon mode, updating the python file will restart the daemon. It's pretty slick.
Another thing you could look at if Django is overkill is Werkzeug, which is pretty much just the server interface. Then later you can add database access with SqlAlchemy and/or templating with Jinja2. Or not.
These pieces are pretty much what people use when they want Django as pieces, and I'm told that they're more powerful, if more work to maintain (some assembly required).
Yes you can do that with mod_wsgi, but if you are new to developing Python web applications it is a potentially painful way to go about it. Either way, read the documentation at:
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apache_Alias_Directive
You use AddHander just like you would with CGI or PHP scripts.
if you worked with php also you are familiar to mod_php
also there is mod_python ( http://www.modpython.org/ ) but its not active community ( there is many article how set django with mod_python ( http://docs.djangoproject.com/en/dev/howto/deployment/modpython/ ) )
but its better use wsgi and uwsgi
http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
http://code.google.com/p/modwsgi/
Does there exist some sort of PHP server that can be bundled with a locally-deployed application? It sounds wonky, but the end result is I can't use a remote web server to do anything. Clients will be downloading a package, and the plan is to use a Java backend that reads from a flat file. The flat file contains settings and is modified through a GUI written in HTML/JS, and this is where the server would come in. The forms in HTML should be able to submit to the server, which does a simple file write to the flat file.
Is there any simple, lightweight server that has that simple feature? When running the executable for the application, it would start the installation process for the server before moving the web GUI files to the appropriate locations.
Note that I'm doing this for a client, so I can't quite change the reqs and would rather not discuss their effectiveness. I would be ever thankful if people had suggestions for the server though!
You should check out roadsend php.
It can compile php scripts into a binary with its own build in server.
https://github.com/weyrick/roadsend-php
Nanoweb might do the trick for you, it's an HTTP server written in PHP. So long as the client has a PHP install you should be able to package things up nicely. In fact with a little extra effort you should be able to package up the PHP binary along with your code.
Nanoweb: http://nanoweb.si.kz/
Since PHP 5.4, PHP have a built-in web server and this works on any system where PHP binaries exists.
$ cd ~/public_html
$ php -S localhost:8000
I can't think of any lighter server...
http://php.net/manual/en/features.commandline.webserver.php
If you have a java backend, what do you need php for?
You could simply bundle a small java based webserver.
http://java-source.net/open-source/web-servers
A while ago I created a small web interface for Transmission (mac/linux bittorrent client) that needed to run a local web server with a custom PHP setup. I used lighttpd + php w/ fastcgi. When zipped up, I believe, it weighted in at <3MBs. If you don't need to run any PHP lighttpd is only a few MB's (and light on resources) and offers a very flexible configuration.
Source: http://svn.recurser.com/transmission/trunk/cocoa/
If you're already using Java, you may want to look at Quercus, an implementation of PHP and many common extensions in Java. It's a bit restrictive, but it may fit your needs.
Like unomi, I don't really understand the situation, but I'll assume you do...
Apache is by far the most popular and best-tested platform on which to run PHP, but in theory it should run on any web server that supports CGI/FastCGI. Alternatives include Lighttpd, nginx, and a few dozen others.
Whatever you choose, the key is to pre-configure it and keep it self-contained in its own folder. I think Apache would easily work here. Set it to port 43948 or something; remove all unnecessary modules; pare down the httpd.conf to its most basic requirements; allow only local connections; and write clickable scripts (.bat or .sh or what have you) to start and stop it.
This project is an interesting option...
An embeddable web server designed for (and written in) PHP. it handles
the control of the assigned port, setting common environmental
variables (such as $_SERVER, $_GET, $_POST and $_COOKIE) and calling a
function or method in your application to delegate the request.
The web server is able to be packaged in, and controlled from, your
application. Therefore eliminating the requirement that your user have
a standard web server installed and configured to use your web
application. Combined with a database such as a flat-file database, a
Berkley DB or SQLite, PHP Embeddable Web server can remove the need
for the user to have any specialised libraries installed, except PHP
(which is preinstalled in many Unix and Linux distros).
I have used this. It does work.. It is cool. As easy as...
# php server.php
You kind of have to get your hands dirty.. but it's TINY, a single file, and HIGHLY configurable... Word of warning though.. don't bother with this unless you know what a header, a class, a method, and an object, etc... And be prepared to apply that knowledge.
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.
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!