-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I've this very very special problems and would ask for some hints, any
helpful response is very appreciated :)
The usual story: old system, big, clunky, legacy, PHP4, can't upgrade.
We're having serious problems with MySQL and too many connections and so
on, but we can't find out where the problematic cases are. We've gone
already through lengthy auditing and logging sessions without real success.
So my next idea: I go into the PHP source, in my case specifically into
ext/mysql/php_mysql.c, reactive my old C skills and inject the logging
of connects and queries directly into the source. Because, as ironic as
it sounds, with the HUGE amount of code we have we still were not able
to identify all places where mysql_(p)connect/mysql_query is used,
because of using variable variables and other nice [tm] tricks.
I understand my attempt is brute force and I'm pretty alone out there.
So, actually I would start hacking away this very moment. But, if anyone
has other suggestion how to go for this, it would be very very much
appreciated.
thanks for reading,
-
- Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
- Markus
iD8DBQFGb5Yj1nS0RcInK9ARAq75AJ95JT3BqFblyfd+FUG2EsKbN8TAdgCfQ0c/
YNTYC8qTPHgzIQPxiJsGJW0=
=4wNf
-----END PGP SIGNATURE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
I've this very very special problems and would ask for some hints, any
helpful response is very appreciated :)The usual story: old system, big, clunky, legacy, PHP4, can't upgrade.
We're having serious problems with MySQL and too many connections and so
on, but we can't find out where the problematic cases are. We've gone
already through lengthy auditing and logging sessions without real success.So my next idea: I go into the PHP source, in my case specifically into
ext/mysql/php_mysql.c, reactive my old C skills and inject the logging
of connects and queries directly into the source. Because, as ironic as
it sounds, with the HUGE amount of code we have we still were not able
to identify all places where mysql_(p)connect/mysql_query is used,
because of using variable variables and other nice [tm] tricks.I understand my attempt is brute force and I'm pretty alone out there.
So, actually I would start hacking away this very moment. But, if anyone
has other suggestion how to go for this, it would be very very much
appreciated.thanks for reading,
- Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiD8DBQFGb5Yj1nS0RcInK9ARAq75AJ95JT3BqFblyfd+FUG2EsKbN8TAdgCfQ0c/
YNTYC8qTPHgzIQPxiJsGJW0=
=4wNf
-----END PGP SIGNATURE-------
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Alexey, Stefan,
first thanks for the replies!
Actually I'm in general aware of xdebug, however I didn't know it met my
criteria.
The thing is: I need to know specific information of the mysql operations:
- host,user,pass of connects/pconnects (and which type of connect),
count of connects this very request already had - sql statement on query, execution time, count of how many statements
this very request already had
Additional to that I need information like:
- server ip (multiple servers)
- remote ip
- http host (zillions of vhosts)
- uri
- user agent string
This is what we currently log for debugging, but we're unable to fully
coverage all sources.
As can be seen, my idea was to have a single place where to log things
from all servers/vhosts/applications, because they also make use of the
single mysql.so driver.
Is this possible with xdebug in this manner? With my current information
I really need this information and to my knowledge (falsely?) I can't
this out of xdebug. Probably important to note, I've been using xdebug
in the past, profiling things, but I don't see this possible in
production environment running and getting out the the information I need.
thank you,
-
- Markus
Alexey Zakhlestin wrote:
Hi,
I've this very very special problems and would ask for some hints, any
helpful response is very appreciated :)The usual story: old system, big, clunky, legacy, PHP4, can't upgrade.
We're having serious problems with MySQL and too many connections and so
on, but we can't find out where the problematic cases are. We've gone
already through lengthy auditing and logging sessions without real
success.So my next idea: I go into the PHP source, in my case specifically into
ext/mysql/php_mysql.c, reactive my old C skills and inject the logging
of connects and queries directly into the source. Because, as ironic as
it sounds, with the HUGE amount of code we have we still were not able
to identify all places where mysql_(p)connect/mysql_query is used,
because of using variable variables and other nice [tm] tricks.I understand my attempt is brute force and I'm pretty alone out there.
So, actually I would start hacking away this very moment. But, if anyone
has other suggestion how to go for this, it would be very very much
appreciated.thanks for reading,
- Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGb8eB1nS0RcInK9ARAoi7AJ0THIJ3VH/43Glq7VuxgpFPqlKieQCdHc8/
VLK3Jox+9AfcNzN4bLf/n7E=
=VYuh
-----END PGP SIGNATURE
Hi Markus,
The thing is: I need to know specific information of the mysql operations:
- host,user,pass of connects/pconnects (and which type of connect),
count of connects this very request already had- sql statement on query, execution time, count of how many statements
this very request already had
You can configure xdebug to create a trace log showing the parameters
passed to the called functions. This could be a basis for what you need.
Additional to that I need information like:
- server ip (multiple servers)
- remote ip
- http host (zillions of vhosts)
- uri
- user agent string
A quick and maybe dirty idea that comes to my mind is to add a function
call in your application that has these parameter (easy to gather from
$_SERVER etc.) so they show up in the trace logs. Then it's a matter of
processing a gazillion lines of trace log to get out the information you
need, but at least it should be there.
in the past, profiling things, but I don't see this possible in
production environment running and getting out the the information I need.
Trace logging in a production environment absolutely kills your
performance, so if you have to dedicated test environment, hmmm.
But would you actually create a patched PHP and deploy this in your
production environment. Then I personally would rather opt for running
an xdebug-based trace Sunday morning at 4 am.
Kind regards,
Stefan
--
e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch