In the case of blockmaxsize=1000000, I was testing this earlier but have a small data set so far. I'm running bitcoin 0.12.( I recommend this bitcoin 0.12.0 for p2pool users who have high getblocktemp latency. It reduced mine under 1s which was not the case before and keeps it steady.) My first attempt like the man says there is a problem. Stale rate shot up almost 100% effective rate was (0-38%). It also stagnated payout marginally but i caught the issue because i was keeping an eye on it and acted swiftly so i don't know how much it would have impacted payout in the long run. I though it was bitcoin issue though so i changed some parameters.

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001
maxuploadtarget=144 (I just threw this in but im testing it with max connections so I don't know how effective it is alone.)
maxconnections=20 (Was around 45 when bitcoin started to act up and p2pool started to loss connection.

Things seem good now but something worth mentioning is that p2pool is now relatively synced. Which wasn't the case before.
P2pool was lossing connection to bitcoin so i added -maxconnections and to keep latency down more -maxuploadtarget at lowest recommended levels by developers(144). Which i think could be lower but would hurt the community by slowing down nodes from syncing from what i read.

Other parameters of interest
-maxmempool=       Keep the transaction memory pool below megabytes (default: 300)
-maxreceivebuffer=  Maximum per-connection receive buffer, *1000 bytes (default: 5000)
-maxsendbuffer=       Maximum per-connection send buffer, *1000 bytes (default: 1000)
-bytespersigop               Minimum bytes per sigop in transactions we relay and mine (default: 20)
-datacarrier               Relay and mine data carrier transactions (default: 1)
-datacarriersize               Maximum size of data in data carrier transactions we relay and mine (default: 83)

I'll update my findings once i have some more data. Any info on above parameters would be helpful.