Libsoup patches // Performance metrics
- From: "Ennes, Pieter" <Pieter Ennes ca com>
- To: "libsoup-list gnome org" <libsoup-list gnome org>
- Subject: Libsoup patches // Performance metrics
- Date: Tue, 9 Apr 2013 11:37:27 +0000
Hi,
Linked to below are two old patches to libsoup-2.30 that I'd like to discuss for enhancement:
1) https://bitbucket.org/watchmouse/libsoup/commits/0e514092bb9733f4c548aa65ec13cca24f240b98
A SoupMessage 'got-raw-chunk' event, analogous to the existing 'got-chunk', but emitted just before the chunk
body is decoded. It allows the client to inspect the content as it goes over the wire, which we use to get an
accurate measure of the number of bytes received, but I can imagine it could serve different purposes. Or I
can imagine there are easier ways to obtain the same information.
2) https://bitbucket.org/watchmouse/libsoup/commits/0a1b41879e39e216b61cadc56c320661e3364566
A SoupSession 'connection-starting' event, analogous to 'connection-created', allowing the client to get a
sense of how much time was spent setting up the connection.
Thirdly, I'm interested (but no patch yet) in being able to accurately measure the DNS lookup time per
connection created. However, we could use some guidance for the best implementation considering the async
case and and the recent DNS prefetching work.
Before attempting to rebase these to a more recent branch or trunk, I'm looking for feedback.
For each of these individually:
- Is there a better, more future-proof, or more preferred implementation thinkable to achieve the same
result?
- Is there any interest in having one or more of these signals included in upstream?
For all three combined:
- In general, what would an ideal patch look like that allows the client to collect performance metrics
like 'resolve time', 'connect time', 'ssl (connect) time', 'time to first/last byte', '(de)coded byte sizes',
...? I can imagine that instead of exposing more signals and offloading the measurements to the client, it
may make more sense to let libsoup gather the statistics internally (and conditionally) and expose them via a
new performance debugging method.
- Would there be any interest in having such a more generic patch included in upstream?
Thanks for any feedback, cheers,
- Pieter
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]