Here are some things that may help;<div><br></div><div><b>#1 svn server overloading when all the slaves bootstrap at the same time</b></div><div>The only good work around is to keep an internal read-only svn-mirror that the slaves use instead of the real svn server.</div>

<div><br></div><div>This means that builds must be triggered on the svn-mirror, which may incurs a delay of a few seconds, due to svnsync polling. My hypothesis is that svn has repo-wide locks while committing, so when there are a lot of readers, they are all starved whenever some action is happening. Doing the svn-mirror trick helped us to scale in the range past <i>several hundreds of simultaneous active connections</i>. As a guidance, gclient sync does 8 svn connections per slave by default. Scale that to hundreds of slaves waking up at the same time...</div>

<div><br></div><div><div>Also, serving the read-only svn server from a set of apache frontends helps. We do that with <a href="http://src.chromium.org">src.chromium.org</a>. To be clear, above I was talking about a DMZ-only mirror. It is a different one from the apache frontends. Implementing both has the biggest benefit.</div>

</div><div><br></div><div><br></div><div><b>#2 Using Chromium's git svn clone of webkit</b></div><div>We have a few read only git frontends that are relatively speedy. I just verified and both master@HEAD matches:</div>

<div><font face="'courier new', monospace">git remote add chromium <a href="http://git.chromium.org/external/Webkit.git">http://git.chromium.org/external/Webkit.git</a></font></div><div><font face="'courier new', monospace">git fetch chromium</font></div>

<div><br></div><div>Once you verified that the hash matches locally with:</div><div><font face="'courier new', monospace">git fetch --all</font></div><div><font face="'courier new', monospace">git log -1 origin/master</font></div>

<div><font face="'courier new', monospace">git log -1 chromium/master</font></div><div><br></div><div>Then you may want to;</div><div><div><font face="'courier new', monospace">git config remote.chromium.fetch +refs/heads/*:refs/remotes/origin/*</font></div>

</div><div><font face="'courier new', monospace">git branch -r -D chromium/master</font></div><div><br></div><div>I give no guarantee what-so-ever about freshness, lack of corruption, consistent performance, availability, YMMV, etc.</div>

<div>Note the url has a lower K! </div><div><br></div><div>Note that we also have <font face="'courier new', monospace">WebKit_trimmed.git</font> (note the upper case K!) that is much smaller due to removal of many files chromium developers don't need but it has invalid hashes so <b>do not fetch this one in your current webkit git-svn clone</b>.</div>

<div><br></div><div><br></div><div><b>#3 Buildbot's (absence of) performance</b></div><div>Stefan (cc'ed) is also looking at this and has been profiling our slowest masters for a while. In our case, we are CPU-bound and it looks like we have to tune our caching. Stefan can explain it better than me. You guys probably want to talk together.</div>

<div><br></div><div><br></div><div>Hope this is useful,</div><div><br>M-A</div><div><br><br><div class="gmail_quote">Le 29 février 2012 21:50, William Siegrist <span dir="ltr"><<a href="mailto:wsiegrist@apple.com">wsiegrist@apple.com</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We're back to the slaves overloading svn. The Apple slaves are blocked temporarily while everyone else catches up. Sorry for the inconvenience.<br>


<div class="HOEnZb"><div class="h5"><br>
-Bill<br>
<br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br></div>