What is PHP-FPM and what are its top alternatives?
PHP-FPM, which stands for PHP FastCGI Process Manager, is a process manager designed to optimize and manage the execution of PHP scripts. It allows for better performance and scalability by processing PHP code as a separate processes rather than traditional CGI methods. Key features include process management, better performance, scalable architecture, and support for multiple pools for different websites. However, PHP-FPM may require additional configuration and monitoring, and its setup can be more complex compared to traditional PHP handlers like mod_php.
HHVM: HHVM is an open-source virtual machine designed for executing programs written in PHP and Hack languages. Key features include Just-In-Time compilation, high performance, and support for PHP and Hack languages. Pros include improved performance over PHP-FPM, while cons may include compatibility issues with some PHP extensions.
LiteSpeed Web Server + LSAPI: LiteSpeed Web Server with LSAPI is a high-performance web server with PHP support. Key features include LiteSpeed Cache, HTTP/3 support, and built-in security features. Pros include improved performance and scalability, while cons may include the need for a commercial license for certain features.
Caddy Server: Caddy is an open-source web server with automatic HTTPS and support for PHP processing. Key features include automatic HTTPS configuration, easy deployment, and modular plugin system. Pros include user-friendly configuration, while cons may include compatibility issues with some PHP applications.
OpenLiteSpeed + LSAPI: OpenLiteSpeed with LSAPI is a lightweight open-source web server with PHP support. Key features include performance optimization, LiteSpeed Cache, and HTTP/3 support. Pros include scalability and performance, while cons may include limited support compared to LiteSpeed Enterprise.
Nginx + PHP-FastCGI: Nginx with PHP-FastCGI is a popular web server setup for processing PHP scripts. Key features include high performance, low resource consumption, and support for reverse proxy. Pros include scalability and performance, while cons may include complexity in configuration for beginners.
Apache + mod_fastcgi: Apache web server with mod_fastcgi module allows for processing PHP scripts using FastCGI. Key features include flexibility, support for various programming languages, and extensive module ecosystem. Pros include compatibility with different applications, while cons may include higher resource consumption compared to Nginx.
Lighttpd: Lighttpd is a lightweight open-source web server known for its speed and efficiency. Key features include low memory footprint, fast performance, and support for FastCGI. Pros include speed and efficiency, while cons may include limited module ecosystem compared to Apache or Nginx.
Microsoft IIS + FastCGI: Microsoft Internet Information Services (IIS) with FastCGI module allows for running PHP scripts on Windows servers. Key features include Windows integration, support for PHP, and compatibility with ASP.NET applications. Pros include seamless integration with Windows environments, while cons may include licensing costs for Windows Server.
Cherokee: Cherokee is a lightweight web server with FastCGI support and a user-friendly interface. Key features include simple configuration, extensibility through plugins, and scalability. Pros include ease of use, while cons may include limited community support compared to other solutions.
H2O + mruby: H2O web server with mruby module allows for dynamic content processing with support for scripting languages like Ruby. Key features include performance optimization, scripting language support, and HTTP/2 compatibility. Pros include flexibility, while cons may include limited documentation compared to more established solutions.
Top Alternatives to PHP-FPM
- HHVM (HipHop Virtual Machine)
HHVM uses a just-in-time (JIT) compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. To date, HHVM (and its predecessor HPHPc before it) has realized over a 9x increase in web request throughput and over a 5x reduction in memory consumption for Facebook compared with the PHP 5.2 engine + APC. ...
- PHP
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
- NGINX
nginx [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. According to Netcraft nginx served or proxied 30.46% of the top million busiest sites in Jan 2018. ...
- uWSGI
The uWSGI project aims at developing a full stack for building hosting services. ...
- Sidekiq
Sidekiq uses threads to handle many jobs at the same time in the same process. It does not require Rails but will integrate tightly with Rails 3/4 to make background processing dead simple. ...
- Hangfire
It is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline. It supports all kind of background tasks – short-running and long-running, CPU intensive and I/O intensive, one shot and recurrent. ...
- Resque
Background jobs can be any Ruby class or module that responds to perform. Your existing classes can easily be converted to background jobs or you can create new classes specifically to do work. Or, you can do both. ...
- Beanstalkd
Beanstalks's interface is generic, but was originally designed for reducing the latency of page views in high-volume web applications by running time-consuming tasks asynchronously. ...
PHP-FPM alternatives & related posts
HHVM (HipHop Virtual Machine)
- Very fast30
- Drop-in PHP replacement24
- Works well with nginx14
- Backed by Facebook14
- Open source12
- Statically checked, typed language1
related HHVM (HipHop Virtual Machine) posts
PHP
- Large community951
- Open source817
- Easy deployment765
- Great frameworks487
- The best glue on the web387
- Continual improvements235
- Good old web185
- Web foundation145
- Community packages135
- Tool support125
- Used by wordpress35
- Excellent documentation34
- Used by Facebook29
- Because of Symfony23
- Dynamic Language21
- Cheap hosting17
- Easy to learn16
- Awesome Language and easy to implement14
- Very powerful web language14
- Fast development14
- Composer13
- Flexibility, syntax, extensibility12
- Because of Laravel12
- Easiest deployment9
- Readable Code8
- Fast8
- Most of the web uses it7
- Worst popularity quality ratio7
- Short development lead times7
- Fastestest Time to Version 1.0 Deployments7
- Faster then ever6
- Open source and large community5
- Simple, flexible yet Scalable5
- I have no choice :(4
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)4
- Is like one zip of air4
- Open source and great framework4
- Large community, easy setup, easy deployment, framework4
- Great developer experience4
- Easy to use and learn4
- Cheap to own4
- Easy to learn, a big community, lot of frameworks4
- Walk away2
- Used by STOMT2
- Hard not to use2
- Fault tolerance2
- Great flexibility. From fast prototyping to large apps2
- Interpreted at the run time2
- FFI2
- Safe the planet2
- It can get you a lamborghini1
- Secure1
- Simplesaml1
- Bando1
- Secure0
- So easy to learn, good practices are hard to find22
- Inconsistent API16
- Fragmented community8
- Not secure6
- No routing system3
- Hard to debug3
- Old2
related PHP posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
- Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
- A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
NGINX
- High-performance http server1.4K
- Performance893
- Easy to configure730
- Open source607
- Load balancer530
- Free288
- Scalability288
- Web server225
- Simplicity175
- Easy setup136
- Content caching30
- Web Accelerator21
- Capability15
- Fast14
- High-latency12
- Predictability12
- Reverse Proxy8
- The best of them7
- Supports http/27
- Great Community5
- Lots of Modules5
- Enterprise version5
- High perfomance proxy server4
- Reversy Proxy3
- Streaming media delivery3
- Streaming media3
- Embedded Lua scripting3
- GRPC-Web2
- Blash2
- Lightweight2
- Fast and easy to set up2
- Slim2
- saltstack2
- Virtual hosting1
- Narrow focus. Easy to configure. Fast1
- Along with Redis Cache its the Most superior1
- Ingress controller1
- Advanced features require subscription10
related NGINX posts
Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.
We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.
Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.
- Faster6
- Simple4
- Powerful2
related uWSGI posts
I find I really like using GitHub because its issue tracker integrates really well into my project flow and the projects feature allows me to organize different efforts into boards. The automation features allow my issues to automatically progress through some states on the boards when I merge pull requests.
My Python / Django app is deployed on Heroku with PostgreSQL database and uWSGI webserver.
I use Gunicorn because does one thing - it’s a WSGI HTTP server - and it does it well. Deploy it quickly and easily, and let the rest of your stack do what the rest of your stack does well, wherever that may be.
uWSGI “aims at developing a full stack for building hosting services” - if that’s a thing you need then ok, but I like the principle of doing one thing well, and I deploy to platforms like Heroku and AWS Elastic Beanstalk where the rest of the “hosting service” is provided and managed for me.
- Simple124
- Efficient background processing99
- Scalability60
- Better then resque37
- Great documentation26
- Admin tool15
- Great community14
- Integrates with redis automatically, with zero config8
- Stupidly simple to integrate and run on Rails/Heroku7
- Great support7
- Ruby3
- Freeium3
- Pro version2
- Dashboard w/live polling1
- Great ecosystem of addons1
- Fast1
related Sidekiq posts
We decided to use AWS Lambda for several serverless tasks such as
- Managing AWS backups
- Processing emails received on Amazon SES and stored to Amazon S3 and notified via Amazon SNS, so as to push a message on our Redis so our Sidekiq Rails workers can process inbound emails
- Pushing some relevant Amazon CloudWatch metrics and alarms to Slack
In 2012 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.
Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.
PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.
Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!
Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.
We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).
Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service
- Integrated UI dashboard7
- Simple5
- Robust3
- In Memory2
- Simole0
related Hangfire posts
Resque
- Free5
- Scalable3
- Easy to use on heroku1
related Resque posts
- Fast23
- Free12
- Does one thing well12
- Scalability9
- Simplicity8
- External admin UI developer friendly3
- Job delay3
- Job prioritization2
- External admin UI2
related Beanstalkd posts
I used Kafka originally because it was mandated as part of the top-level IT requirements at a Fortune 500 client. What I found was that it was orders of magnitude more complex ...and powerful than my daily Beanstalkd , and far more flexible, resilient, and manageable than RabbitMQ.
So for any case where utmost flexibility and resilience are part of the deal, I would use Kafka again. But due to the complexities involved, for any time where this level of scalability is not required, I would probably just use Beanstalkd for its simplicity.
I tend to find RabbitMQ to be in an uncomfortable middle place between these two extremities.