php / php/frankenphp

Document and perform benchmarks

Open
#481 28 comments 8 reactions 1 assignee View on GitHub

@withinboredom is already working on this.

Since Jan 17, 2024.

documentation
Dominant language
Go
Stars
11.3k
Forks
488
Avg merge
4d 10h
Merged PRs (30d)
11

Description

This is an issue to perform some "scientific" benchmarks, leveraging 20 years of finagling this stuff. Scientific is in quotes because I intend this to be a scientific endeavor, but read on.

Goals:

  1. Fully tuned php.ini
  2. Fully tuned nginx + fpm
  3. Fully tuned apache
  4. Discover caddy + FrankenPHP's best tuning
    • What Go environment variables make a difference, and how to set them
    • Compilation options?
    • worker mode vs. cgi mode vs. static binary
  5. Documentation to perform the benchmarks
    • kernel settings/parameters
    • device characteristics (arm/x86/etc, cores, etc)
    • use rented device that is cheap and always available -- anyone should be able to reproduce -- but also represent realistic production machines.

Non-goals:

  1. Generic benchmarking suite (I am not building anything)
  2. Framework benchmarks (Not comparing frameworks)

Known Caveats:

  1. Extensions and code will make a difference, but if the documentation is good enough, people can perform their benchmarks with their desired configuration.
  2. The PHP code under test must be chosen carefully to illustrate typical PHP characteristics from the perspective of a SAPI (setting headers, outputting data, JIT'able code, etc.)
  3. From casual testing, we're much more likely to saturate network links long before CPU with FrankenPHP, thus we either need high performing links, or underpowered machines. Needs further investigation.

Considerations:

  • Considering terraform for technical documentation + writeup of approach/whys.
  • We will probably want to have #440 released by PHP to test CGI mode properly.
  • Many people use containers/Kubernetes; testing multiple nginx|caddy|apache running on the same machine in separate containers would be interesting. Mostly out of curiosity: does horizontal scaling on the same machine make a difference, or is vertical scaling better?

Related:

#444

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.