I'm working on a suite of tests using selenium webdriver (written in Python).  The page being tested contains a form that changes its displayed fields based upon what value is selected in one of its select boxes.  This select box has about 250 options.  I have a test (running via nose, though that's probably irrelevant) that iterates through all the options in the select box, verifying that the form has the correct fields displayed for each selected option.
The problem is that for each option, it calls through selenium:

click for the option to choose
find_element and is_displayed for 7 fields
find_elements for the items in the select box
get_attribute and text for each option in the select box

So that comes out to (roughly) 250 * (7 * 2 + 1 + 2 * 250), or 128,750 distinct requests to the webdriver server the test is running on, all within about 10 or 15 minutes.  This is leading to client port exhaustion on the machine running the test in some instances.  This is all running through a test framework that abstracts away things like how the select box is parsed, when new page objects are created, and a few other things, so optimizations in the test code either mean hacking that all to hell or throwing away the framework for this test and doing everything manually (which, for maintainability of our test code, is a bad idea).
Some ideas I've had for solutions are:

Trying to somehow pool or reuse the connection to the webdriver server
Somehow tweaking the configuration of urllib2 or httplib at runtime so that the connections opened by selenium timeout or are killed more quickly
System independent (or at least implementable for all systems with an OS switch or some such) mechanism for actively tracking and closing the ports being opened by selenium

As I mentioned above, I can't do much to tweak the way the page is parsed or handled, but I do have control over subclassing/tweaking WebDriver or RemoteConnection any way I please.  Does anyone have any suggestions on how to approach any of the above ideas, or any ideas that I haven't come up with?
In as much as a small amount of plastic explosive solves the problem of forgetting your house keys, I implemented a solution.  I created a class that tracks a list of resources and the time they were added to it, blocks when a limit is reached, and removes entries when their timestamp passes beyond a timeout value.  I then created an instance of this class setup with a limit of 32768 resources and a timeout of 240 seconds, and had my test framework add an entry to the list every time webdriver.execute() is called or a few other actions (db queries, REST calls) are performed.  It's not particularly elegant and it's quite arbitrary, but at least so far it seems to be keeping my tests from triggering port exhaustion while not noticeably slowing tests that weren't causing port exhaustion before.
tcp/ip port exhaustion with selenium webdriver