Alternatives to PHP-FPM logo

Alternatives to PHP-FPM

HHVM (HipHop Virtual Machine), PHP, NGINX, uWSGI, and Sidekiq are the most popular alternatives and competitors to PHP-FPM.
92
92
+ 1
0

What is PHP-FPM and what are its top alternatives?

It is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites. It includes Adaptive process spawning, Advanced process management with graceful stop/start, Emergency restart in case of accidental opcode cache destruction etc.
PHP-FPM is a tool in the Background Processing category of a tech stack.

Top Alternatives to PHP-FPM

  • HHVM (HipHop Virtual Machine)

    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

    PHP

    Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...

  • NGINX

    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

    uWSGI

    The uWSGI project aims at developing a full stack for building hosting services. ...

  • Sidekiq

    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

    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

    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

    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) logo

HHVM (HipHop Virtual Machine)

131
128
95
An open-source virtual machine designed for executing programs written in Hack and PHP
131
128
+ 1
95
PROS OF HHVM (HIPHOP VIRTUAL MACHINE)
  • 30
    Very fast
  • 24
    Drop-in PHP replacement
  • 14
    Works well with nginx
  • 14
    Backed by Facebook
  • 12
    Open source
  • 1
    Statically checked, typed language
CONS OF HHVM (HIPHOP VIRTUAL MACHINE)
    Be the first to leave a con

    related HHVM (HipHop Virtual Machine) posts

    PHP logo

    PHP

    114K
    58.4K
    4.5K
    A popular general-purpose scripting language that is especially suited to web development
    114K
    58.4K
    + 1
    4.5K
    PROS OF PHP
    • 942
      Large community
    • 806
      Open source
    • 759
      Easy deployment
    • 482
      Great frameworks
    • 385
      The best glue on the web
    • 234
      Continual improvements
    • 182
      Good old web
    • 143
      Web foundation
    • 133
      Community packages
    • 124
      Tool support
    • 33
      Used by wordpress
    • 31
      Excellent documentation
    • 26
      Used by Facebook
    • 23
      Because of Symfony
    • 19
      Dynamic Language
    • 15
      Cheap hosting
    • 14
      Awesome Language and easy to implement
    • 14
      Very powerful web language
    • 13
      Fast development
    • 11
      Easy to learn
    • 11
      Composer
    • 10
      Because of Laravel
    • 10
      Flexibility, syntax, extensibility
    • 8
      Easiest deployment
    • 7
      Readable Code
    • 7
      Worst popularity quality ratio
    • 7
      Short development lead times
    • 7
      Fastestest Time to Version 1.0 Deployments
    • 6
      Faster then ever
    • 6
      Fast
    • 6
      Most of the web uses it
    • 5
      Simple, flexible yet Scalable
    • 5
      Open source and large community
    • 4
      Has the best ecommerce(Magento,Prestashop,Opencart,etc)
    • 4
      Cheap to own
    • 4
      Easy to use and learn
    • 4
      I have no choice :(
    • 4
      Large community, easy setup, easy deployment, framework
    • 4
      Open source and great framework
    • 4
      Is like one zip of air
    • 4
      Easy to learn, a big community, lot of frameworks
    • 3
      Great developer experience
    • 2
      Hard not to use
    • 2
      Walk away
    • 2
      Fault tolerance
    • 2
      Used by STOMT
    • 2
      Great flexibility. From fast prototyping to large apps
    • 2
      Interpreted at the run time
    • 2
      Safe the planet
    • 2
      FFI
    CONS OF PHP
    • 20
      So easy to learn, good practices are hard to find
    • 16
      Inconsistent API
    • 8
      Fragmented community
    • 5
      Not secure
    • 2
      No routing system
    • 1
      Hard to debug
    • 1
      Old

    related PHP posts

    Nick Rockwell
    SVP, Engineering at Fastly · | 44 upvotes · 1.8M views

    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.

    See more
    Simon Reymann
    Senior Fullstack Developer at QUANTUSflow Software GmbH · | 25 upvotes · 2.2M views

    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.
    See more
    NGINX logo

    NGINX

    95.4K
    45.6K
    5.5K
    A high performance free open source web server powering busiest sites on the Internet.
    95.4K
    45.6K
    + 1
    5.5K
    PROS OF NGINX
    • 1.4K
      High-performance http server
    • 896
      Performance
    • 728
      Easy to configure
    • 606
      Open source
    • 529
      Load balancer
    • 286
      Scalability
    • 285
      Free
    • 222
      Web server
    • 173
      Simplicity
    • 134
      Easy setup
    • 29
      Content caching
    • 19
      Web Accelerator
    • 14
      Capability
    • 13
      Fast
    • 11
      Predictability
    • 10
      High-latency
    • 7
      Reverse Proxy
    • 6
      Supports http/2
    • 4
      The best of them
    • 4
      Lots of Modules
    • 4
      Enterprise version
    • 4
      Great Community
    • 3
      High perfomance proxy server
    • 3
      Streaming media
    • 3
      Embedded Lua scripting
    • 3
      Reversy Proxy
    • 3
      Streaming media delivery
    • 2
      Fast and easy to set up
    • 2
      Lightweight
    • 2
      Slim
    • 2
      saltstack
    • 1
      Virtual hosting
    • 1
      Blash
    • 1
      GRPC-Web
    • 1
      Ingress controller
    • 1
      Narrow focus. Easy to configure. Fast
    • 1
      Along with Redis Cache its the Most superior
    • 0
      A
    CONS OF NGINX
    • 8
      Advanced features require subscription

    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.

    See more
    Gabriel Pa
    Shared insights
    on
    TraefikTraefikNGINXNGINX
    at

    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

    See more
    uWSGI logo

    uWSGI

    193
    265
    9
    uWSGI application server container
    193
    265
    + 1
    9
    PROS OF UWSGI
    • 5
      Faster
    • 3
      Simple
    • 1
      Powerful
    CONS OF UWSGI
      Be the first to leave a con

      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.

      See more

      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.

      See more
      Sidekiq logo

      Sidekiq

      1K
      557
      407
      Simple, efficient background processing for Ruby
      1K
      557
      + 1
      407
      PROS OF SIDEKIQ
      • 123
        Simple
      • 99
        Efficient background processing
      • 60
        Scalability
      • 37
        Better then resque
      • 26
        Great documentation
      • 15
        Admin tool
      • 14
        Great community
      • 8
        Integrates with redis automatically, with zero config
      • 7
        Great support
      • 7
        Stupidly simple to integrate and run on Rails/Heroku
      • 3
        Freeium
      • 3
        Ruby
      • 2
        Pro version
      • 1
        Fast
      • 1
        Dashboard w/live polling
      • 1
        Great ecosystem of addons
      CONS OF SIDEKIQ
        Be the first to leave a con

        related Sidekiq posts

        Cyril Duchon-Doris

        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
        See more

        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.

        On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .

        For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.

        See more
        Hangfire logo

        Hangfire

        117
        166
        16
        Perform background processing in .NET and .NET Core applications
        117
        166
        + 1
        16
        PROS OF HANGFIRE
        • 6
          Integrated UI dashboard
        • 5
          Simple
        • 3
          Robust
        • 2
          In Memory
        • 0
          Cons
        • 0
          Simole
        CONS OF HANGFIRE
          Be the first to leave a con

          related Hangfire posts

          Resque logo

          Resque

          110
          106
          9
          A Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later
          110
          106
          + 1
          9
          PROS OF RESQUE
          • 5
            Free
          • 3
            Scalable
          • 1
            Easy to use on heroku
          CONS OF RESQUE
            Be the first to leave a con

            related Resque posts

            Beanstalkd logo

            Beanstalkd

            107
            131
            74
            A simple, fast work queue
            107
            131
            + 1
            74
            PROS OF BEANSTALKD
            • 23
              Fast
            • 12
              Free
            • 12
              Does one thing well
            • 9
              Scalability
            • 8
              Simplicity
            • 3
              External admin UI developer friendly
            • 3
              Job delay
            • 2
              Job prioritization
            • 2
              External admin UI
            CONS OF BEANSTALKD
              Be the first to leave a con

              related Beanstalkd posts

              Frédéric MARAND
              Core Developer at OSInet · | 2 upvotes · 190.4K views

              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.

              See more