<div dir="ltr">Hi Mads,<div><br></div><div>We're using postgres for our db.  I didn't mention it because it doesn't seem to be playing any real role in the overall utilization.  We're also using celery and rabbitmq.  We did have a problem for a while that our Jenkins CI system was overrunning the Kallithea with all kinds of pull requests that were polling for any CI changes.  I've switched that over to use Mercurial hooks to let Jenkins know when something changes.  That seems to have made a big difference.</div><div><br></div><div>I think now the issue may be overall clone & pull speed, but maybe I'm wrong.  Do any of the settings inside production.ini have any affect on that, or are we talking raw Mercurial performance once pulls and clones take over?  Also, would there be any benefit to having my CI systems use SSH for their activity rather than HTTP?</div><div><br></div><div>Sorry for all of the questions, but I'm not quite sure where to look....</div><div><br></div><div>Tim</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 26, 2015 at 4:30 PM, Mads Kiilerich <span dir="ltr"><<a href="mailto:mads@kiilerich.com" target="_blank">mads@kiilerich.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/26/2015 10:01 PM, Tim Downey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
I'm running a Kallithea instance with about 100 repositories and healthy amount of CI activity across several branches on each repository.  I'm looking for some tips on tuning performance.  I'm running using waitress (at least I think I am) and see what look like several knobs in the production.ini file that can be turned, but I'm not really sure what I'm looking at.<br>
<br>
See below for my settings.  Can anyone point towards what I can be looking at or changing?  I appear to be CPU bound, not io or mem.  Most of my activity is the result of my CI activity, not users through the web interface.<br>
</blockquote>
<br></span>
Normal Python was not designed for multi core CPUs. Neither was Mercurial ... even though hgweb should handle multi threading correctly. (I use largefiles which do horrible hacks with live monkey patching of modules and I would not dare to use that multithreaded.)<br>
<br>
I would suggest a setup with multiple worker processes. I don't know how feasible that is with the Python web servers. It seems like people then put another web server / proxy in front of them - which in my opinion gives a much more complicated setup.<br>
<br>
I am a relatively happy user of apache + mod_wsgi. It scales nicely with multiple single-threaded worker processes but might require more memory. (I might however investigate uwsgi.)<br>
<br>
I am surprised you don't mention your database. Could it be that you are using sqlite and you need something that is less light?<span class="HOEnZb"><font color="#888888"><br>
<br>
/Mads<br>
<br>
</font></span></blockquote></div><br></div>