Analyze slow request report

[Paul Everitt]

Get with Rossi and get the data we are collecting as part of the LP task you did a few weeks ago for the slow request report. (If it wasn't enabled in production, try to get it enabled.)

Stare at the data and mash it around a little, then report back with your opinions on what (if any) we might have problems with. In particular, I have a suspicion that some stuff running prefix matching (LiveSearch, member lookups, etc.) are slow.

[Tres Seaver (tseaver)]

For reference, the earlier work was done against lp:523805.

The change there was to make the repoze.debug:responselogger middleware part of the pipeline in 'etc-develop/karl.ini'. I don't believe that this change is in production (at least, it isn't checked into 'etc-deploy/karl.ini' or 'etc-staging/karl.ini').

[Paul Everitt (paul-agendaless)]

Tres, I guess this can get back on the radar, since Friday's update put the collection into production?

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Everitt wrote:
> Tres, I guess this can get back on the radar, since Friday's update put
> the collection into production?

I didn't verify that the data was being collected: in fact, I doubt I
have access to the box. Once there is a few days worth of requests
logged (in /path/to/karl/log/trace.log) I will be glad to take a look at
it and make recommendations.

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvfBf4ACgkQ+gerLs4ltQ75pQCfaPXWyN1vxdX6vGa6ELe+m34W
jkcAn0sbf3WQU58nNH7s13t65d00KVkB
=fLtu
-----END PGP SIGNATURE-----

[Paul Everitt (paul-agendaless)]

Grabbed the data from /opt/karl3/log/*trace* and sent to Tres for analysis.

[Tres Seaver (tseaver)]

Analysis of the week's data from 2010-05-26 to 2010-06-02 indicates that the
following types of requests represent the majority of the "slow" requests (those
over 30 second median):

- Large PDF, images, or MSOffice files (about 50%).

- Community views, especially those with non-default batch parameters.

- Folders within a 'files' tool.

Most of these request URLs are potential "outliers" (only requested once).

[Paul Everitt (paul-agendaless)]

I don't think there's a next step on this, per Tres's analysis. I was looking for outliers that reflected something we really need to look at on view code, such as slow searches or tag pages.