This has been bugging me for awhile now.
In a deployed PHP web application one can upload a changed php script and have the updated file picked up by the web server without having to restart.
The problem? Ruby, Groovy, & Python, etc. are all "better" than PHP in terms of language expressiveness, concision, power, ...your-reason-here.
Currently, I am really enjoying Groovy (via Grails), but the reality is that the JVM does not do well (at all) with production dynamic reloading of application code. Basically, Permgen out of memory errors are a virtual guarantee, and that means application crash at anytime -- not good.
Ruby frameworks seem to have this solved somewhat from what I have read: Passenger has an option to dynamically reload changed files in polled directories on the next request (thus preventing connected users from being disconnected, session lost, etc.).
Standalone Python I am not sure about at all; it may, like PHP allow dynamic reloading of python scripts without web server restart.
As far as our web work is concerned, invariably clients wind up wanting to make changes to a deployed application regardless of how detailed and well planned the spec was. Telling the client, "sure, we'll implement that [simple] change at 4AM tomorrow [so as to not wreak havoc with connected users]", won't go over too well.
As of 2011 where are we at in terms of dynamic reloading and scripting languages? Are we forever doomed, relegated to the convenience of PHP, or the joys of non-PHP and being forced to restart a deployed application?
BTW, I am not at all a fan of JSPs, GSPs, and Ruby, Python templating equivalents, despite their reloadability. This is a cake & eat it too thread, where we can make a change to any aspect of the application and not have to restart.
You haven't specified a web server. If you're using Apache, mod_wsgi is your best bet for running Python web apps, and it has a reloading mechanism that doesn't require a server restart.
I think you're making a bigger deal out of this than it really is.
Any application for which it is that important that it never be down for 1/2 a minute (which is all it takes to reboot a server to pick up a file change) really needs to have multiple application server instances in order to handle potential failures of individual instances. Once you have multiple application servers to handle failures, you can also safely restart individual instances for maintenance without causing a problem.
Related
Since locally, I did only php artisan serve and it works fine.
In my production VM, I am not sure if I should just do the same php artisan serve &
so I don't have to install Nginx, configure the document root, and so on.
Are there any disadvantages in doing that?
nginx
designed to solve c10k problem
performs extremely well, even under huge load
is a reverse proxy
uses state of the art http parser to check whether request is even valid
uses extremely powerful yet simple config syntax
comes with plethora of modules to deal with http traffic (auth module, mirror module)
can terminate ssl/tls
can load balance between multiple php serving endpoints (or any other endpoints that speak http)
can be reloaded to apply new config, without losing current connections
php artisan serve
designed to quickly fiddle with laravel based website
written in php, isn't designed to solve c10k problem
will crash once available memory is exceeded (128 mb by default, that gets quickly filled up)
isn't a reverse proxy
isn't using state of the art http parser
isn't stress tested
can't scale to other machines the way nginx does
doesn't terminate SSL. Even if it did, it would be painfully slow compared to a pure compiled solution
isn't event-based or threaded the way php-fpm/nginx are so everything executes in the same process. There's no reactor pattern for offloading to workers to scale across cpu cores and protect against bringing the server down if a piece of code is messed up. This means if you load too much data from MySQL - process goes down, therefore the server too.
Configuring nginx takes about ~30 seconds on average, for experienced person. I'm speaking from experience since it's my daily job. Using automation tools like ansible makes this even easier, you can almost forget about it.
Using a web server designed to fiddle and quickly test a part of your code in production comes with risks. Your site will be slower. Your site will be prone to crashing if any script kiddie decides to run a curl request in a foreach loop.
If you think installing and configuring nginx is a hassle and you want to go with php artisan serve, make sure you run it supervised (supervisord is my go to tool). If it crashes, it'll boot up back again.
In my opinion, it's worthless to run a php-based server to serve your app. The amount of time spent to configure nginx / php-fpm isn't humongous, even if you're new to it.
Everything comes with risks and gains, but in this particular case - the gain doesn't exist, while there's certainty that something will go wrong.
TL;DR
Don't do it, spend those few minutes configuring nginx. The best software is the one that does the work well to that point you can forget about it. nginx is one of those tools. PHP excels in many areas, but built-in webserver is not one of those things that you should use in production. Go with tools proven in the battle field.
The php artisan serve never should be used on the production environment as it is using the PHP7 built-in server functionality which is designed to development purposes only.
See this page
So, please avoid using in production. Instead, use Apache or Nginx, which both are good choices, depending on your needs. Nginx may be usually faster(not always).
Currently I'm working with PHP programming, and I find that I can load a web page just only by using PHP CL, so I don't understand exactly why we have to install additional server like Apache or Nginx.
I don't know why your question was voted down. I see it as a question for focusing on a slightly broader but highly related question: Why should we be extremely careful to only allow specific software onto public-facing infrastructure? And, even more generally, what sort of software is okay to place onto public-facing infrastructure? And its corollary, what does good server software look like?
First off, there is no such thing as secure software. This means you should always hold a very skeptical view of anything that opens a single port on a computer to enable network connections (in either direction). However, there is a very small set of software that has had enough eyeballs on it to guarantee a certain minimum level of assurance that things will probably not go horribly wrong. Apache is the most battle-tested server out there and Nginx comes in at a close second as far as modern web servers are concerned. The built-in PHP HTTP server is not a good choice for a public-facing system let alone testing production software as it lacks the qualities of good network server design and may have undiscovered security vulnerabilities in it. For those and other reasons, the developers include a warning against using the built-in PHP server. It was added because users kept asking for it but that doesn't mean it should be used.
It is also a good idea to not trust network servers written by someone who doesn't know what they are doing. I frequently see ill-conceived network servers written in Node or Go, typically WebSocket-based solutions or just used to work around some issue with another piece of software, that implicitly opens security holes in the infrastructure even if the author didn't intend to do so. Just because someone can do something doesn't mean that they should and, when it comes to writing network servers, they shouldn't. Frequently those servers are proxied behind Apache or Nginx, which affords some defense against standard attacks. However, once an attacker gets past the defenses of Apache or Nginx, it's up to the software to provide its own defenses, which, sadly, is almost always significantly lacking. As a result, any time I see a proxied service running on a host, I brace myself for the inevitable security disaster that awaits - Ruby, Node, and Go developers being the biggest offenders. The moment a developer decides to write a network server is the moment they've probably chosen the wrong strategy unless they have a very specific reason to do so AND must be aware of and prepared to defend against a wide range of attack scenarios. A developer needs to be well-versed in a wide variety of disciplines before taking on the extremely difficult task of writing a network server, scalable or otherwise. It is my experience that few developers out there are actually capable of that task without introducing major security holes into their own or their users' infrastructure. While the PHP core developers generally know what they are doing elsewhere, I have personally found several critical bugs in their core networking logic, which shows that they are collectively lacking in that department. Therefore their built-in web server should be used sparingly, if at all.
Beyond security, Apache and Nginx are designed to handle "load" more so than the built-in PHP server. What load means is the answer to the question of, "How many requests per second can be serviced?" The answer is actually extremely complicated. Depending on code complexity, what is being hosted, what hardware is in use, and what is running at any point in time, a single host can handle anywhere from 20 to 20,000 requests per second and that number can vary greatly from moment to moment. Apache comes with a tool called Apache Bench (ab) that can be used to benchmark performance of a web server. However, benchmarks should always be taken with a grain of salt and viewed from the perspective of "Can we get this application to go any faster?" rather than "My application is faster than yours."
As far as developing software in PHP goes (since SO is a programming question site), I recommend trying to mirror your production environment as best as possible. If Apache will be running remotely, then running Apache locally provides the best simulation of the real thing so that there aren't a bunch of last-minute surprises. PHP code running under the Apache module may have significantly different behavior than PHP code running under the built-in PHP server (e.g. $_SERVER differences)!
If you are like me and don't like setting up Apache and PHP and don't need Apache running all the time, I maintain a set of scripts for setting up portable versions of Apache, PHP, and Maria DB (roughly equivalent to MySQL) for Windows over here:
https://github.com/cubiclesoft/portable-apache-maria-db-php-for-windows/
If your software application is actually intended to be run using the built-in PHP server (e.g. a localhost only server), then I highly recommend introducing a buffer layer such as the CubicleSoft WebServer class:
https://github.com/cubiclesoft/ultimate-web-scraper/
By using a PHP userland class like that one, you can gain certain assurances that the built-in PHP server cannot provide while still being a pure PHP solution (i.e. no extra dependencies): Fewer, if any, buffer overflow opportunities, the server is interpreted through the Zend Engine resulting in fewer rogue code execution opportunities, and has more features than the built-in server including complete customization of the server request/response cycle itself. PHP itself can start such a server during an OS boot by utilizing a tool similar to Service Manager:
https://github.com/cubiclesoft/service-manager/
Of course, that all means that a user has to trust your application's code that opened a port to run on their computer. For example, what happens if a website starts port scanning localhost ports via the user's web browser? And, if they do find the port that your software is running on, can that website start deleting files or run code that installs malware? It's the unusual exploits that will really trip you up. A "zero open ports" with "disconnected network cable/disabled WiFi" strategy is the only known way to truly secure a device. Every open port and established connection carries risk.
Good network-enabled software will have been battle-tested and hardened against a wide range of attacks. Writing such software is a responsibility that takes a lot of time to get right and it will generally show if it is done wrong. PHP's built-in server feels sloppy and lacks basic configuration options. I can't recommend its use for any reasonable purpose.
If you refer to the PHP documentation:
Warning
This web server was designed to aid application development. It may
also be useful for testing purposes or for application demonstrations
that are run in controlled environments. It is not intended to be a
full-featured web server. It should not be used on a public network.
http://php.net/manual/en/features.commandline.webserver.php
So yes, as it states, this is a good tool for testing purposes. You can quickly start a server and test your scripts in your browser. But that does not mean it provides all of the features you get with a production level server like apache or Nginx :)
You can use the built in server in your local development environment. But you should you use a more secure, feature rich web server in your production environment which requires much more features in terms of security, handling large number of requests etc.
I'm needing to design a work order management system that will be accessed via a web browser, using PHP, and will interface with an arbitrary embedded database. For the time being this application will be stand alone, and will need to have a very easy setup. I want to stay away from a full blown Apache setup for the time being. Obviously I will need some sort of web server to serve up the PHP pages, and anything that can't be built into the database or PHP will probably be written in Python. I'm thinking it might be easiest to have everything built into this single Python instance, but I'm up for suggestions.
Really what I'm trying to stay away from is having multiple services running at any given time that all need updating and maintenance. I'll be running this at work on a single machine and it will need to keep a low profile. Any suggestions?
I've always worked with Apache, MySQL, and PHP. I'd like to eventually branch out to Python/Django or Ruby/Ruby on Rails, but that's another discussion. Two great things about Apache, MySQL, and PHP are all three are ubiquitous and it's very easy to launch a website. Just set up an Apache virtual host, import the database into MySQL, and copy the PHP files onto the server. That's it. This is all I've ever done and all I've ever known. Please keep this in mind.
These days, it's becoming increasingly important for websites to be able to deliver data in real-time to the users. Users expect this too due to the live nature of Facebook and Gmail. This effect can be faked with Ajax polling, but that has a lot of overhead, as explained here. I'd like to use WebSockets. Now remember that I've always been a LAMP guy. I've only ever launched websites using the method I described earlier. So if I have, say, a CakePHP site, how can I "add on" the feature of WebSockets? Do I need to install some other server or something or can I get it to work smoothly with Apache? Will it require Apache 2.4? Please explain the process to me keeping in mind that I only know about LAMP. Thanks!
One key thing to keep in mind, is that a realtime websockets server needs to be "long running", so that it can push stuff to clients. In the classic LAMP setup, Apache spawns a PHP interpreter on each request. Between requests the PHP interpreter is not running, and the only protocol state kept between requests is sessions.
One nice property of the LAMP way, is that memory management is easy. You just implicitly allocate whatever memory you need, and it is automatically reclaimed when the request is done, and the PHP process exits. As soon as you want the server to keep running, you need to consider memory management. In some laguages, like C++, you manage allocation and deallocation explicitly. In other languages, like Java or Javascript, you have garbage collection. In PHP you throw everything away, and start with a fresh slate on each request.
I think you will have a hard time making long running servers with something like Cake or any other classic PHP framework. Those frameworks works by basically taking an HTTP request and turning it into an HTTP response.
My advice is that you should look into something like Node.JS and SocketIO. If you know Javascript, or don't mind learning, these technologies allow you to easily implement real-time servers and clients. If necessary you could run a reverse proxy like nginx, so that your existing LAMP stack would get some requests, and one or more NodeJS servers would get some.
This answer came out a bit fluffy, but I hope that it helps a little.. :-)
I found there are a lot of articles comparing Nginx and Apache in Internet. However, all these comparisons are based on stress test to web server running PHP code. I suppose this is mainly due to Apache is generally deployed with PHP as LAMP architecture.
In my understanding, Nginx is created to solve C10K problem with event-based architecture. That is, Nginx is supposed to serve M concurrent requests with N threads/processes. N is supposed to much less than M. This is a big difference from Apache which needs M threads/processes to serve M concurrent requests.
For PHP code, the programming model is not asynchronous. Each web request would occupy one thread/process for PHP to handle it. So, I don't understand the meaning to compare Nginx and Apache with PHP code.
The event-based architecture of Nginx must excels Apache especially when requests involves I/O operations. For example, requests need to merge results from multiple other web services. For Apache+PHP, each requests might takes seconds just waiting for I/O operation complete. That would consume a lot of threads/processes. For Nginx, this is not a problem, if asynchronous programming is used.
Would it make more sense to deploy Nginx with language supporting asynchronous programming model?
I'm not sure which programming language could dig most potential from Nginx, but it id definitely not PHP.
First and foremost, nginx does not support any application execution directly.
It can serve static files, proxy requests to any other webserver and some other small things.
Historically, nginx aimed to handle many network connections, true, but the rationale was this:
until apache respond to the request of someone on slow connection, it can do nothing.
Apache has a limit of workers, so when there are lots of slow clients, anyone new have to wait until
a worker finishes the transfer and resumes accepting new request.
So the classic setup is nginx accepting external requests, proxying them to the local apache;
apache handles the requests and gives back the responses to the nginx to transfer to the clients.
Thus apache is eliminated from dealing with clients.
Regarding the question and nginx in the picture. It's not that hard to utilize
system event frameworks these days. That's epoll for Linux, kqueue for FreeBSD
and others. At the application level lots of choices, twisted for python for
example. So all you have to do is to write application with these frameworks,
which 1) usually put you in async world and 2) give you a way
to build HTTP service, ready to be backend for nginx.
That's probably where you are aiming at.
So, c10k doesn't seem to be a problem for nginx,
nor for applications built around these frameworks.
Example at hand is friendfeed's tornado server:
python written, uses epoll and kqueue depending on the system,
handles up to 8k easyly, as i recall. There were some benchmarks
and afterthought to scale it further.
Something must be brewing in ruby world about all the async trend,
so they can come up with, if they haven't already.
Ruby's passenger and mongrel, whatever in essense they are (i'm blanking on this),
do work with nginx, and this required writing modules for nginx.
So the community takes nginx into account and does extra when it needs to.
Php, by the way, stays relevant for pushes when websockets massively deployed. Oh well.
The point is that potential doesn't matter. PHP is something of a standard for web development and so is what people usually care about with servers, so just because Ngnix or Apache are optimised to run an obscure programming language y times faster than the other is irrelevant unless it's PHP.