Tested with 40 GHs (one 10GHs node and one 30Ghs node), unfortunately, for some reason, the 30GHs node bad-performed.
I did install proxy but it was not able to upload more than 5-6 results per second (20 - 25Ghs) with alot of shares spending too much time in upload queue to the point where they would become obsolete after new job.
This is not happening on direct connection with btc pool, upload queue is almost always empty.
Example
1347652578.006 TS, Submitter2, extracted id=0, data=0
1347652578.168 TS, Submitter2, net-looped id=0, data=0
1347652578.213 TS, Submitter2, extracted id=1, data=0
1347652578.374 TS, Submitter2, net-looped id=1, data=0
1347652578.374 TS, Submitter2, extracted id=2, data=0
1347652578.535 TS, Submitter2, net-looped id=2, data=0
1347652578.535 TS, Submitter2, extracted id=3, data=0
1347652578.696 TS, Submitter2, net-looped id=3, data=0
1347652578.696 TS, Submitter2, extracted id=4, data=0
1347652578.857 TS, Submitter2, net-looped id=4, data=0
1347652578.857 TS, Submitter2, extracted id=5, data=0
1347652579.017 TS, Submitter2, net-looped id=5, data=0
1347652579.017 TS, Submitter2, extracted id=6, data=0
1347652579.177 TS, Submitter2, net-looped id=6, data=0
1347652579.177 TS, Submitter2, extracted id=7, data=0
1347652579.338 TS, Submitter2, net-looped id=7, data=0
1347652579.338 TS, Submitter2, extracted id=8, data=0
1347652579.499 TS, Submitter2, net-looped id=8, data=0
1347652579.499 TS, Submitter2, extracted id=9, data=0
1347652579.659 TS, Submitter2, net-looped id=9, data=0
1347652579.660 TS, Submitter2, extracted id=10, data=0
1347652579.820 TS, Submitter2, net-looped id=10, data=0
extracted happens just before httplib conn.request and
net-looped happens after httplib conn.getresponse().read(), id is queue id for work result to submit.