Re: Apache::DBI + DBD::Oracle performance problem

Super short version: client thinks the server is slow, server thinks the client is slow. Sounds like a network problem to me. You might want to try doing some network diagnostics while experiencing these slow downs. There are many ways in which things could be messed up: bad hardware, bad wires, bad configurations. And it could be at the IP layer (if the server and client are not on the same LAN), or at the ethernet layer.

Specific examples I've seen like this are: bad ethernet cables (sad but true), some sort of @#$%ed up arrangement of your switches (cycles or diamonds in your topology), ethernet interfaces renegotiating their speed/duplex, instead of just being locked down, bad routes, etc.

Anyway, just a wild stab in the dark.

------------
:Wq
Not an editor command: Wq
[download]

Comment on Re: Apache::DBI + DBD::Oracle performance problem Download Code

Replies are listed 'Best First'.

Re^2: Apache::DBI + DBD::Oracle performance problem
by jhourcle (Prior) on Mar 31, 2005 at 03:00 UTC

Some other annoying network quirks that I've run into:

Ethernet collisions (okay, this one's easy... look for a segment in your trace that's unswitched, and see if the hub's blinking too much)
Network card on fire (look for the smoke)
Incorrect autonegotiation (one thinks it's full duplex, the other thinks half duplex)
Too many hops on an ethernet segment. (should not go through more than 3 repeaters... shouldn't be a problem on a switched network).
Poorly seated cables. (pull them all out, push them back in fully).
Crosstalk (or other inductance). (not typically an issue, unless you're running incorrectly spec'd cables, or near phone/power lines)

More often than not, though, it's either a saturated network, or like etcshadow said, and it's a bad cable (poorly made, crushed, improper radius, nicked, etc.) or misconfigured. (bad hardware happens, but once you're burned in, it's fairly rare in my experience)

If you can sniff the network on either end, I'd suggest doing it, and see if you can spot anything wrong. You also have to remember that you're not running a real time OS (very few people are, as they can cause worse overall performance in most situations), so you can't be assured that anything is going to happen within a certain time frame.

[reply]


Perl: the Markov chain saw
	PerlMonks