Speeding up PHP & Javascript runtimes.

Last Significant Update:

2024-07-05

Status:

Draft

Comments to:

mensurae@jkoshy.net

ⲙⲉⲓ (Maat) is an SRE working for large webhosting company hosting millions of websites.  Maat’s boss, Ra, has commanded her to make the site’s operation more ‘virtuous’.

The site runs on PHP and Javascript.  Maat figures that she needs to improve the runtimes for these two languages, but isn’t sure where to start.

Maat tries conventional ‘tick’-based and hardware counter-based profiling first, but she quickly discovers that conventional profiling does not go very far when dealing with interpreted languages.

Maat’s colleague Thoth recommends that she look at the Mensurae toolkit as an alternative.  Maat discovers that this toolkit has been designed from the start for applications to measure their own behavior on hardware.[1]

Maat starts by adding starts by instrumenting the PHP and Javascript runtimes using Mensurae’s APIs for self-measurement.  She deploys her instrumented runtimes to production, and starts collecting information about the behavior of these language runtimes when running the actual workloads in production.

Maat collects information about instruction counts & cache misses per interpreted ‘opcode’, the behaviour on hardware of JIT’ed code, the hardware behavior of the garbage collectors involved, the behavior of the locks in the code, and so on.  She then uses this data to guide performance improvements to these runtimes.

Design Considerations

Self-measurement API

Mensurae’s self-measurement APIs would be built using hardware support for application self-measurement.[2]  Mensurae will need to offer easy-to-use APIs that abstract away the machine-dependent parts.[3]

Production Stability

Mensurae’s APIs and other infrastructure (e.g., trace collection) should not cause instability.

Low-overheads

Mensurae’s instrumentation should not introduce significant overheads to production software.

Query Language

Mensurae needs to offer an expressive query language for analyzing its collected data.

1. This particular feature (PMC_OP_PMCX86GETMSR) has been in FreeBSD’s HWPMC since its inception.
2. Such as the RDPMC (Read Performance Monitoring Counter) instruction on x86.
3. Interpreting the meaning of the data gathered would still be machine architecture dependent.  This is unavoidable when dealing with low-level measurements of this nature.