Extending ltrace to make your Ruby/Python/Perl/PHP apps faster(timetobleed.com)
timetobleed.com
Extending ltrace to make your Ruby/Python/Perl/PHP apps faster
http://timetobleed.com/extending-ltrace-to-make-your-rubypythonperlphp-apps-faster/
8 comments
This is very cool stuff. I usually debug my programs through log messages, but this looks to be much easier / less performance impact.
I don't know what you mean by less performance impact; ltrace works by putting software breakpoints into the functions you want to trace, and such breakpoints work by causing a soft interrupt (e.g. INT 3 on x86), which causes a drop into kernel mode and invokes the appropriate interrupt handler, then the kernel suspends the process that caused the interrupt and queues the ltrace process which is ptrace-ing your app to be woken up when the scheduler thinks it's convenient, then ltrace has to write out its output after it figures out why it was woken up, yadda yadda, etc etc... overall it's pretty heavy-weight in comparison to a log message, but in practice is probably only a negligible performance impact for 99.9%+ of programs.
Right but I can selectively run ltrace, where as my logging statements are always in the code, and if statements have to be evaluated etc
It's not about performance; it's about not having logging statements in the code and/or having to add them when something goes awry.
One shouldn't remove asserts() just because you're going to ship code, you just #define assert() to expand nothing. Same applies to languages other than C that don't have a pre-processor: you can define a null function, and hopefully your runtime is awesome enough to optimize calls to it away.
What am I missing? all mysql calls have to go over a system call, so strace will see them (as write() or send() I guess).
Why use ltrace for this job?
Why use ltrace for this job?
Using strace to trace mysql traffic is painful. You have to know which file descriptors to trace (check via lsof first), then trace all network traffic on those fds in verbose mode to see the queries themselves (doesn't work if the mysql protocol has compression enabled), and then try to figure out how long each of the queries took to execute by matching queries and responses.
ltraceing mysql_send_query() gives you all this information in one line.
ltraceing mysql_send_query() gives you all this information in one line.
Plus, you can trace a lot more than mysql queries.. commonly used libraries like libMagick, libxml, libcurl, libmemcached, and even internal VM functions like garbage_collect(), PyEval_SafeThread(), etc.