view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

### `ENDOSCOPE` VARIANT

        $ wrk 'http://localhost:3000/hello' -R 2500 -d 60
        Running 1m test @ http://localhost:3000/hello
          2 threads and 10 connections
          Thread calibration: mean lat.: 686.950ms, rate sampling interval: 2496ms
          Thread calibration: mean lat.: 680.839ms, rate sampling interval: 2420ms
          Thread Stats   Avg      Stdev     Max   +/- Stdev
                Latency     4.59s     1.87s    8.80s    58.91%
                Req/Sec     1.09k    10.68     1.11k    70.00%
          130455 requests in 1.00m, 18.56MB read
        Requests/sec:   2174.22
        Transfer/sec:    316.77KB

### DISCUSSION

The baseline program delivered 2365 requests per second in the face of clients
demanding 2500 requests per second. The `Endoscope` variant delivered 2174
requests per second, or 91.92% of baseline. In other words, `Endoscope` in the
given configuration reduces capacity by about 8.1%.

8.1% can be seen as a lower bound on overhead with a query firing once per
request on saturated, CPU-bound Mojolicious web apps. Queries that fire more
than once per request, or which do expensive work while exporting data, may
have a higher impact. However, most real-world applications:

- Do not run at their 'red line' of capacity, and
- Do significantly more work than render out "Hello World".

So, you are encouraged to measure for yourself.

#### UNSATURATED

In order to avoid misrepresenting the performance of Mojolicious (or my laptop
:)), here's an example "unsaturated" test case, which is representative of the
performance of both the baseline and the variant. I won't specify which one
this is, because the variance from run to run is too high to get a meaningful
ordering:

        $ wrk 'http://localhost:3000/hello' -R 2000 -d 60
        Running 1m test @ http://localhost:3000/hello
          2 threads and 10 connections
          Thread calibration: mean lat.: 5.213ms, rate sampling interval: 10ms
          Thread calibration: mean lat.: 5.041ms, rate sampling interval: 10ms
          Thread Stats   Avg      Stdev     Max   +/- Stdev
                Latency     4.28ms    0.88ms  21.57ms   92.20%
                Req/Sec     1.05k   122.54     1.67k    65.38%
          119971 requests in 1.00m, 17.07MB read
        Requests/sec:   1999.48
        Transfer/sec:    291.31KB

# SECURITY

`Endoscope` is a powerful tool for debugging running systems by inspecting
their memory. This means that anyone who is able to configure `Endoscope`
queries and view their output can read the contents of nearly any variable
present in memory. As such, access to these capabilities should be carefully
guarded.

For example, if `Endoscope` is integrated into a web framework and exposes
a special HTTP endpoint for configuring queries, that endpoint should only be
accessible from the host where the application is running, not externally.
Additionally, that HTTP endpoint should be gated by strong
authentication/authorization.

# SEE ALSO

- [Devel::Optic](https://metacpan.org/pod/Devel::Optic)
- [Devel::Probe](https://metacpan.org/pod/Devel::Probe)
- [Enbugger](https://metacpan.org/pod/Enbugger)