Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

There's a compromise here: the more connections, the faster your node will be notified of new blocks and avoid wasting work, the faster it can include transactions with fees in the coinbase and the faster it will propagate a P2Pool block minimizing chances it would become orphan.
But the less connections, the less bandwidth used and the lower the latency.

More than 20 for maxconnections is probably overkill: from my experience (trying various values from 6 to 100) it seems there's not much gain to have past this value (and if you don't have enough WAN bandwidth it can hurt your latencies by queuing transfers between P2Pool nodes during peaks).
Note that this may change in the future if the behavior of bitcoind/P2Pool network changes: when in doubt, monitor your interface(s) bandwidth usage and raise this value when most peaks are below your link capacity.

If your orphan rate is fine, don't tempt the devil and try tuning maxconnections below 20: you may reduce your income more than you increase it...

Warning: P2Pool needs one connection to bitcoind and bitcoind tries to fill all the allowed connections after startup. If you start P2Pool just after bitcoind (or before, it will repeatedly try to connect), it shouldn't have problem connecting because bitcoind will still have connection slots available. If you set maxconnections too low P2Pool might not succeed connecting.

For P2Pool, you can do the same by passing parameters to P2Pool:
Note: orphans will quickly rise if you have very few connections (they are the means to be notified of other shares after all). I would prefer reducing bitcoind connections before P2Pool's.

In my experience you can get as low as 6 total connections (3 in, 3 out) without noticeable efficiency changes. The default values seem overkill (6 outgoing, 40 incoming). The large number of incoming connections (--max-conns) is designed to help the whole network (some nodes are behind firewalls that don't allow incoming connections). You probably should allow more incoming connections (and check that your network setup allows incoming connections) to do your part in helping the network.

one of my miners is an ASICMiner Eruptor Blade, which i believe uses getwork, but i am still seeing the hash > target msgs on the cli fly by...

any idea as to why it would still be doing this considering its using getwork? and is there anything that can be done to fix?

Notice that says scrypt with cgminer which does not apply to bitcoin. Eruptors don't have any way to set difficulty, they have extremely simple mining software built in that only does diff 1. You could probably use the stratum proxy by slush between the blades and your p2pool software to get rid of the message, but not sure if that really gains you anything but adds another layer ...

when i first tried p2pool all i did was point my miner at p2pool.org. After a while my graph was showing hashrate + payout.

now if i try it my graph shows hashrate but never get payout. i never knew about setting up p2pool before hand i just pointed miner at it.

is it even possible to use p2pool that way? or do you HAVE to run bit coin/p2pool aswell?

why do the graphs never show any payout, even if i left it on for over 24 hours. But the first time i ever used p2pool it was showing payout within a couple of hours ?!

this is a normal message when using blades. what you want to do is add: +1 to the end of your username on the blade web interface. this will force p2pool to always give the blade diff1 work, since it only knows diff 1 anyways. this will stop those log messages. you might see one or two here or there..... also the blades dont seem to work with p2pool via stratum mining proxy.