
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Has anyone had any luck with trying out some tracing/coverage with the openstack projects to see where the bottlenecks are (outside of test coverage)?</div><div><br></div><div>I was thinking about possible ways to do this (there seems to be a lot of different libraries that might help) but was wondering if anyone else has figured out the best one to use yet.</div><div><br></div><div>Ideally it should have the following properties (in my mind):</div><ol><li>Non-intrusive (shouldn't require sprinkling of timing/trace logic all over)</li><li>Works with eventlet/greenlet (eventlet is going to switch things in and out, so that has to be taken account of)</li><li>Probably does this via sampling (?)</li><li>Writes out some standard format (valgrind like?) for analysis…</li><li>Can be turned on and off remotely (nice to have, it'd be cool to have an API/entrypoint/… that says enable tracing which can be used on a live system, that system will become slower but it'd be neat)</li><ul><li>This could be some special 'admin' entry point (restricted to certain users of course) that could also do stuff like 'reload-configs' or 'enable-tracing' or 'adjust-log-level' or similar administrative actions that would be useful during those crazy debug sessions (think a simple admin telnet entrypoint to view stats, similar to what memcache/redis provide via there 'stats' commands…)</li></ul></ol><div>Anyone have any ideas on this :-)</div><div><br></div><div>-Josh </div></body></html>