With version 1.44 the notifyCommit wget request returns in well under a second (almost instantly). With Jenkins Subversion plugin 1.45 the notifyCommit wget returns in around 20 seconds. This basically means that even if we configure wget to have a 30 second timeout (and not retry) all SVN commits take ~20 seconds at a minimum!

This slow response time is made worse by having this being called by a post-commit hook in SVN and the prescribed wget call doesn't provide a 'tries' argument to limit retries. This causes wget to retry 20 times. The symptom is that I updated Jenkins and SVN commits suddenly take minutes of time (due to the interaction between wget retrying and the notifyCommit call taking 20 seconds).

I suspect this slowness has to do with svn:externals being resolved as that was added in 1.45 (Fixed: support for svn:externals (issue #16217 and issue #13790) and we have a lot of externals. If this is the case I would think that notifyCommit could return a response before resolving svn:externals.

I posted this question on the Google Group as well: https://groups.google.com/forum/?fromgroups=#!searchin/jenkinsci-dev/subversion%7Csort:date/jenkinsci-dev/nFGCnv_xyv4/a5IGqI1Hox0J

I can also provide more information if needed, just let me know what I can do or what would be helpful.

Steps to reproduce:
-Have an SVN repository with quite a few svn:externals (I haven't created a repository from scratch to test - I just know we have quite a few externals and have seen in the log them being resolved on when notifyCommit is called)
-Set up a post commit hook as per https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin to notify jenkins on commit.
-Perform a SVN commit and notice it takes a long time (2 minutes) to commit.
-Check the access log and you can see wget retrying about 20 times. If you run wget manually against notifyCommit and it will take about 20 seconds - far longer than the 2 second limit.