Perrin Harkins wrote:
Malcolm J Harwood wrote:
Somehow I managed to miss the existence of DBI::Profile. Has anyone
gotten this working with Apache::DBI (so that it aggregates across the
entire lifetime of the DB connection)?
Just use DBI::ProfileDumper::Apache.
I don't believe thats been p
Malcolm J Harwood wrote:
Somehow I managed to miss the existence of DBI::Profile. Has anyone gotten
this working with Apache::DBI (so that it aggregates across the entire
lifetime of the DB connection)?
Just use DBI::ProfileDumper::Apache.
- Perrin
> >You can look at the tuning information on http://modperlbook.org/ for
> >some advice as well. And don't forget that there is a profiler for DBI
> >queries that comes with DBI.
Somehow I managed to miss the existence of DBI::Profile. Has anyone gotten
this working with Apache::DBI (so that it
> I don't know it's even possible in mysql. Its reference docs doesn't say
> that it is (http://dev.mysql.com/doc/mysql/en/join.html).
>
Yes it does :
http://dev.mysql.com/doc/mysql/en/identifier-qualifiers.html
Hmmm... Excellent!!! I'll use it then...Will let you know how it goes...
Thanks
> I don't know it's even possible in mysql. Its reference docs doesn't say
> that it is (http://dev.mysql.com/doc/mysql/en/join.html).
>
Yes it does :
http://dev.mysql.com/doc/mysql/en/identifier-qualifiers.html
Clinton
Apache::DProf uses the debugger hooks. You can also try Sam Tregar's
Devel::Profiler::Apache which is somewhat slower but easier to use since it
doesn't use the debugger.
I'll look into that...
Thanks for your suggestions...
---
Badai Aqrandista
Cheepy (?)
Badai Aqrandista wrote:
use lib '/i4u/web/elres-mp';
#require Apache::DB;
#Apache::DB->init;
PerlRequire /i4u/web/elres-mp/etc/startup.pl
PerlModule Apache::DProf
PerlModule ELRes::ELRes
PerlModule ELRes::ApacheHandler
PerlTransHandler ELRes::Apache
It does look odd. Maybe you are still loading some code before calling
Apache::DB->init(). Can you post your httpd.conf, or at least the mod_perl
part of it?
start of mod_perl configuration ...
use lib '/i4u/web/elres-mp';
#require Apache::DB;
#Apache::DB->i
Badai Aqrandista wrote:
As I said previously, the handler itself tops everything... I don't know
why it happens...
It does look odd. Maybe you are still loading some code before calling
Apache::DB->init(). Can you post your httpd.conf, or at least the
mod_perl part of it?
If I use Devel::
Okay, send it again with the top 10, sorted by -r then. Maybe we can
make more suggestions.
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
20.5 14.30 15.222 1 14.305 15.222 ELRes::ApacheHandler::handler
0.37 0.261 0.261 99576 0. 0. Date::Simple::as_
On Wed, 2005-08-17 at 10:15 +1000, Badai Aqrandista wrote:
> >Was the previous output sorted with the -r flag though?
>
> No.
Okay, send it again with the top 10, sorted by -r then. Maybe we can
make more suggestions.
- Perrin
Was the previous output sorted with the -r flag though?
No.
There's no trick, it's the same as in any language: find out what the
slow parts are by using a profiler and tinker with them until they are
faster.
You can look at the tuning information on http://modperlbook.org/ for
some advice
On Wed, 2005-08-17 at 09:23 +1000, Badai Aqrandista wrote:
> I got the previous output because I put in the debugger initialization...
Was the previous output sorted with the -r flag though? It just seems
so unlikely that Params::Validate would take significant time.
If it was sorted with -r, it
I do all of my memcached stuff , including sessions, with mysql failover.
its barely more code - i just make every public function address two
private functions.
ie:
sub save {
$_[0]->_save_memcached();
$_[0]->_save_mysql();
}
sub load {
if ( !$_[0]->_load_memcache
I also suspect that you didn't initialize the debugger before compiling
your code, since none of your code appears in this output.
I got the previous output because I put in the debugger initialization...
Without initialization (Apache::DB->init), this is the top 5 output before
the cache is f
Hi,
I'm assuming that each client database is contained within the same
MySQL server, and that you're not running 300 MySQL servers on different
machines or different ports?
Yes, why would I do that?
If so, you can reuse the same connections, and just reference the
different database in the
On Aug 16, 2005, at 11:17 AM, Perrin Harkins wrote:
Good plan. This would make a nice addition (as a separate module) to
the Apache::Session::Memcached distribution.
I'll see if I can figure out how to make:
Apache::Session::Memcached::WithFailover
where it does that behavior, but then allo
Jonathan Vanasco wrote:
I do all of my memcached stuff , including sessions, with mysql
failover.
Good plan. This would make a nice addition (as a separate module) to
the Apache::Session::Memcached distribution.
- Perrin
On Aug 16, 2005, at 9:49 AM, Perrin Harkins wrote:
If you can use Apache::Session::Memcached, why can't you use
Apache::Session::MySQL with a common database login? That will mean
one connection per apache process. You can also raise the connection
limit on your database server if it isn't dy
Badai Aqrandista wrote:
Yes, I'm aware of that. The problem is that the database structure is a
reminiscent of the old version, which creates one database per client.
It used to be only 40 clients and one web server. Now we have 300+
clients (=300+ databases) and 2 web servers. I always get 'To
> Yes, I'm aware of that. The problem is that the database structure is a
> reminiscent of the old version, which creates one database per client. It
> used to be only 40 clients and one web server. Now we have 300+ clients
> (=300+ databases) and 2 web servers. I always get 'Too many connectio
On 16 Aug 2005, at 06:55, Badai Aqrandista wrote:
Badai Aqrandista wrote:
My mod_perl web app uses memcached to cache most of the (MySQL)
database query results and as the session storage
(Apache::Session::Memcached).
Would it be a problem for your application if you suddenly lost
Badai Aqrandista wrote:
My mod_perl web app uses memcached to cache most of the (MySQL) database
query results and as the session storage (Apache::Session::Memcached).
Would it be a problem for your application if you suddenly lost all of your
session data? That could happen with memcached
Badai Aqrandista wrote:
My mod_perl web app uses memcached to cache most of the (MySQL) database
query results and as the session storage (Apache::Session::Memcached).
Would it be a problem for your application if you suddenly lost all of
your session data? That could happen with memcached.
UPDATE: I hadn't done much testing when I wrote this... Well, after a bit
more testing they don't wait for each other apparently...
Sorry for filling up your mailbox...
But the actual question remains: How to optimize this web app? I'll send
more questions later with more details...
Thanks f
Hi all,
My mod_perl web app uses memcached to cache most of the (MySQL) database
query results and as the session storage (Apache::Session::Memcached). When
doing performance tests with httperf, I found that apache processes waits
for each other. I mean: all requests are accepted (apache forks
26 matches
Mail list logo
