What is PHP-FPM and what are its top alternatives?
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. ...
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
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. ...
The uWSGI project aims at developing a full stack for building hosting services. ...
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. ...
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. ...
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. ...
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
- 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
- Large community942
- Open source806
- Easy deployment759
- Great frameworks482
- The best glue on the web385
- Continual improvements234
- Good old web182
- Web foundation143
- Community packages133
- Tool support124
- Used by wordpress33
- Excellent documentation31
- Used by Facebook26
- Because of Symfony23
- Dynamic Language19
- Cheap hosting15
- Awesome Language and easy to implement14
- Very powerful web language14
- Fast development13
- Easy to learn11
- Because of Laravel10
- Flexibility, syntax, extensibility10
- Easiest deployment8
- Readable Code7
- Worst popularity quality ratio7
- Short development lead times7
- Fastestest Time to Version 1.0 Deployments7
- Faster then ever6
- Most of the web uses it6
- Simple, flexible yet Scalable5
- Open source and large community5
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)4
- Cheap to own4
- Easy to use and learn4
- I have no choice :(4
- Large community, easy setup, easy deployment, framework4
- Open source and great framework4
- Is like one zip of air4
- Easy to learn, a big community, lot of frameworks4
- Great developer experience3
- Hard not to use2
- Walk away2
- Fault tolerance2
- Used by STOMT2
- Great flexibility. From fast prototyping to large apps2
- Interpreted at the run time2
- Safe the planet2
- So easy to learn, good practices are hard to find20
- Inconsistent API16
- Fragmented community8
- Not secure5
- No routing system2
- Hard to debug1
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:
- 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.
- High-performance http server1.4K
- Easy to configure728
- Open source606
- Load balancer529
- Web server222
- Easy setup134
- Content caching29
- Web Accelerator19
- Reverse Proxy7
- Supports http/26
- The best of them4
- Lots of Modules4
- Enterprise version4
- Great Community4
- High perfomance proxy server3
- Streaming media3
- Embedded Lua scripting3
- Reversy Proxy3
- Streaming media delivery3
- Fast and easy to set up2
- Virtual hosting1
- Ingress controller1
- Narrow focus. Easy to configure. Fast1
- Along with Redis Cache its the Most superior1
- Advanced features require subscription8
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.
We switched to Traefik so we can use the REST API to dynamically configure subdomains and have the ability to redirect between multiple servers.
We still use nginx with a docker-compose to expose the traffic from our APIs and TCP microservices, but for managing routing to the internet Traefik does a much better job
The biggest win for naologic was the ability to set dynamic configurations without having to restart the server
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.
- Efficient background processing99
- Better then resque37
- Great documentation26
- Admin tool15
- Great community14
- Integrates with redis automatically, with zero config8
- Great support7
- Stupidly simple to integrate and run on Rails/Heroku7
- Pro version2
- Dashboard w/live polling1
- Great ecosystem of addons1
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
I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.
- Integrated UI dashboard6
- In Memory2
related Hangfire posts
- Easy to use on heroku1
related Resque posts
- Does one thing well12
- 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.