Comment 7 for bug 567180

I set up a local Launchpad instance and made a client invoke createComment with an 8 megabyte comment. The total elapsed time was 21 seconds, but the way the time was distributed was very interesting:

T Event
000 Client sends 8 megabyte POST
002 Request logged to Zope access log
002 Zope tracelog "B"
002 Zope tracelog "I", POST size identified
004 Zope tracelog "-", target URL identified
007 Zope tracelog "A", response code identified
007 Control returns to client

Then the client sends a GET for the newly created comment.

007 Zope tracelog "B"
021 Zope tracelog "A"

The POST isn't exactly fast, but the GET afterwards is twice as slow as the POST. When a POST has a return value of 201, launchpadlib automatically fetches the newly created object. I've verified that subsequent GETs to the comment URL are also very slow, and it's probably also going to be slow to get the comment collection. I haven't profiled it, but it doesn't help that that 8 megabyte string has to be encoded as JSON.

There are a couple solutions. This is yet another argument for "merge proposal attachment", since anything this huge should really be its own resource, and we've optimized file-type resources to handle the "big blob of unprocessed data" case. We could also stop launchpadlib from making that subsequent GET, and return a shim object on 201 that will fetch a representation only if you end up using the object.