As you correctly surmise, this is a non-trivial task. There is a whole class of tools called "APM" (Application Performance Monitoring) which sell for as much as $100K that do this. However, if you were running on Solaris, you could use 'dtrace' to do this. All you need to know are the C entry points in the various tiers. You may want to see whether SystemTap can help. If you were running the Java version, you could also do this with a little bit of effort using JVMTI or BTrace. Heh - this could be a research paper on it's own !
In general, it is much better to do this using external frameworks than building out such complex functionality within Olio. Shanti On Wed, Jun 9, 2010 at 3:55 PM, Vasileios Kontorinis <[email protected]>wrote: > Akara/Shanti/olio-dev hi, > Here is what I am currently trying to do. I need a relative estimate > of how much time is spend on the db queries, the requests from the filestore > (NFS rpcs) and the web-server processing the user requests. Ideally, this > can be a great feature for Olio. Imagine having to debug a performance issue > and olio providing an average breakdown of response time to web/db/filestore > time. It would immediately tell you where you should start looking for the > problem. Additionally would immediately tell you how much you can improve > you performance by upgrading your storage hardware, optimizing your queries, > adding more resources to your web-server etc. > I understand this is pretty hard to implement, because db queries, > filestore accesses can be done by multiple files and proper accounting > should be supported by Faban (send back to the users/master). > Some thoughts: > - *Where to start: *It appears that the php code on the server side is the > only place where this can be done. > - *Storage:* This makes sense only per user, so the session is probably a > logical place to store this info. > - *Organization*: Since response time is measured per operation with > Faban, this also needs to be per operation. > - *Timestamps:* I believe from php I could use getMicroTime() before I > start a query, call it again after it's done and get a diff. > - *Overhead:* Since I will have to log the result in the sessions for > every operation this will likely be a performance killer. Sampling can be > applied to do logging every 100 requests or so. > > Insights, ideas are most welcome. > > Thanks > ------------------------------------------------------------------- > Kontorinis Vasileios > Phd student, University of California San Diego > http://cseweb.ucsd.edu/~vkontori/ <http://cseweb.ucsd.edu/%7Evkontori/> > [email protected] > ------------------------------------------------------------------- >
