Looking at fiddler and Jenkins logs to find why Jenkins is taking a long time to load pages.
It appears that to just display a build page, we believe that Jenkins attempts to deserialize a ~4 MB XML file containing test results, even if there are no failures. That means for a standard GitHub PR, stashpop is causing 20 MB of XML to be deserialized (which ultimately needs to be GC'd)
We found that the same doesn't occur if you go through the APIs, which in the end provide the same amount of information. Right now, the build HTML page takes ~12 seconds to load, whereas, going through the APIs takes ~100ms.
While we figure out to fix this, it would be great if stashpop used the APIs to avoid this:
Looking at fiddler and Jenkins logs to find why Jenkins is taking a long time to load pages.
It appears that to just display a build page, we believe that Jenkins attempts to deserialize a ~4 MB XML file containing test results, even if there are no failures. That means for a standard GitHub PR, stashpop is causing 20 MB of XML to be deserialized (which ultimately needs to be GC'd)
We found that the same doesn't occur if you go through the APIs, which in the end provide the same amount of information. Right now, the build HTML page takes ~12 seconds to load, whereas, going through the APIs takes ~100ms.
While we figure out to fix this, it would be great if stashpop used the APIs to avoid this:
Instead of: http://dotnet-ci.cloudapp.net/job/roslyn_prtest_lin_dbg_unit32/4230
Use: http://dotnet-ci.cloudapp.net/job/roslyn_prtest_lin_dbg_unit32/4230/api/json
You can add "?pretty=true" to the end to get a formatted view:
http://dotnet-ci.cloudapp.net/job/roslyn_prtest_lin_dbg_unit32/4230/api/json?pretty=true