Just wondering there is any kind of stress test I can put the ASA through. I'm asking this not to help with a problem but just for reference.
I know I could use iperf to send a bunch of traffic through it but was thinking there might be something more I could do.
For a firewall device It is quite common to stress test the throughput capacity and simultaneous connections (and in some scenarios even the maximum size of the NAT translation table).
Then there is the amount of new connections per unit of time the firewall device can establish (rate of new connections).
This parameter is of huge significance in a firewall and in my experience, not many people talks about it and as a consequence, not many people do test it.
In fact, a couple of times I have seen firewalls fell on their knees under a DDoS that is well under the maximum advertised throughput of the firewall but which has a very high connection rate (last I remember above ~100Kconns/sec).
When this happens the explaining is not always easy to do:
"What do you mean with a 100Mbps DDoS our firewall fell???, isn't it supposed to handle Zillions of Gbps of throughput??? I want to talk with the sales engineer right know dammit!"
Kudos for even thinking about stress testing. In my experience you really have to break down the components of the firewall and design your tests for specific circumstances depending on your policies and configuration. @jliendo pointed out some good items for consideration. Connections per second instead of merely throughput is important to think about and you could try a real-world test of that by downloading a heavily seeded torrent. Your device could also have the IPS card installed so if it did, you'd want to thoroughly test stress any policies that you setup for packet inspection with the sensor. Did you setup Antivirus scanning? You would want to test throughput of that policy to see if it can keep up. In general, the goal of a stress test would be to test your policies more so than the raw power of the hardware; since the policies can significantly impact the performance levels of the hardware.
With the above in mind, you would find a collection of tools such as iperf to help you analyze specific cases. Iperf can help you test your storm control policies. Seagull is a useful traffic generator that can test most of your other policies. (Remember to test whether or not it works as intended, AND whether it blocks traffic as intended) Depending on your environment you may also want to test latency and poor network connections (perhaps the 5505 is a branch-office firewall?) to help you adjust your timeouts. The trial version of Netlimiter is very helpful in this regard.
In summary I would re-approach your question from the view of your configuration. If you have configured the box to allow or deny traffic in a certain situation, then ask yourself how to test whether or not that works as intended. Once you tested at this level, then try to test multiple policies (such as HTTP through the AV Scan to a secondary subnet on a VLAN). Then bomb the device to death with a traffic generator, find weak points in the flow, and setup quality of service to protect yourself in the case of extreme situations.