Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Stas Bekman wrote: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... Try DBIx::Profile. I've had great success with it. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Stas wrote: possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... Definitely release it! It is a very elegant solution to a problem that I'm guessing many of us have dealt with. I've always _tried_ to write a db abstraction layer, so this kind of profiling would be easy. But I can easily think of two cases where i was trying to track down bad queries and this little trick would have saved me a lot of time. [ couldn't you have telepathically told me how to do this a year ago?? ] it would be a nice addition to the guide too. aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Stas Bekman wrote: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... Try DBIx::Profile. I've had great success with it. Ouch, I was checking the wrong namespace DBI:: and that's why I've missed it. Why DBIx? Looks like it does pretty much the same but returns too much info, which makes it quite hard to use when you have 100+ queries in some requests :) And fetch()es are quite irrelevant for performance improvements since they never change unless you compare TCP/IP vs UNIX sockets or one driver against the other. My aim was to have one to tune the code when I'm in a given environment... The only problem with DBIx::Profile is that you have to turn Apache::DBI off, since DBIx::Profile overrides disconnect() as well. I suppose if it's still desirable for my hack to go in, it should be at least ProfSimple or ProfQuickDirty :) I also think that it should go into DBI:: tree, since it doesn't use the framework of DBIx:: classes. Or is there any reason for not using DBI::? Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Stas Bekman wrote: Or is there any reason for not using DBI::? Tim mandates it. DBI:: is reserved for DBI only. DBD::* is reserved for DBD drivers only, anything else goes in DBIx. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
It would be nice if Tim Bunce simply added it as a parameter to DBI's existing methods. Why not ask him? Fabrice Aaron Ross wrote: On Tue, 28 Nov 2000, Stas wrote: possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... Definitely release it! It is a very elegant solution to a problem that I'm guessing many of us have dealt with. I've always _tried_ to write a db abstraction layer, so this kind of profiling would be easy. But I can easily think of two cases where i was trying to track down bad queries and this little trick would have saved me a lot of time. [ couldn't you have telepathically told me how to do this a year ago?? ] it would be a nice addition to the guide too. aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Wed, 29 Nov 2000, Fabrice Scemama wrote: It would be nice if Tim Bunce simply added it as a parameter to DBI's existing methods. Why not ask him? I think most people would prefer to see it as a separate module. Generally people do their query optimisations outside of DBI (and Perl), using the database's in-built profilers. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Stas Bekman wrote: Looks like it does pretty much the same but returns too much info, which makes it quite hard to use when you have 100+ queries in some requests :) I suspect it would be pretty easy to add in a threshold like the one in your module. And fetch()es are quite irrelevant for performance improvements since they never change unless you compare TCP/IP vs UNIX sockets or one driver against the other. I find the fetch information useful when deciding whether to do a more complex query that retrieves fewer results or a simple one that retrieves extra data and then sift through it in perl. You could probably modify DBIx::Profile to support a flag for turning this off. The only problem with DBIx::Profile is that you have to turn Apache::DBI off, since DBIx::Profile overrides disconnect() as well. I didn't turn Apache::DBI off and things still seemed to work. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: DBI::Prof
On Tue, 28 Nov 2000, Matt Sergeant wrote: On Wed, 29 Nov 2000, Fabrice Scemama wrote: It would be nice if Tim Bunce simply added it as a parameter to DBI's existing methods. Why not ask him? I think most people would prefer to see it as a separate module. Generally people do their query optimisations outside of DBI (and Perl), using the database's in-built profilers. This one is not about optimizing the database, but finding the missing indices mostly and seeing which queries might need to be rewritten to make a better use of the driver/db. I don't know how can you do that without actually running your application, which means DBI/Perl. I suppose that if someone will send a necessary patch to Tim he might put it in or not... I'm fine with any of Tim's decisions. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFC: DBI::Prof
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] On Tue, 28 Nov 2000, Stas Bekman wrote: And fetch()es are quite irrelevant for performance improvements since they never change unless you compare TCP/IP vs UNIX sockets or one driver against the other. I find the fetch information useful when deciding whether to do a more complex query that retrieves fewer results or a simple one that retrieves extra data and then sift through it in perl. For some drivers (DBD::Ingres for one) the $sth-execute only optimizes the query, the data is fetched in the first call to fetch. Fetching the first row does all the "real" work, joining and sorting etc. So you will se a very fast prepare time, a not-too-long execute time, and (in some cases) a horribly long fetch-time for the first fetch. -- Henrik Tougaard, [EMAIL PROTECTED] DBD::Ingres maintainer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
