It is not possible to run shell scripts, install other software, or do any kind of serious administrative tasks on Amazon RDS.
In an RDS environment, you're completely isolated from the operating system and from administration of the actual system that is running MySQL for you. Your RDS instance is an opaque black box that you can only communicate with via the MySQL command line client, and even that is not likely to be what you think it is.
I was able to connect to RDS with shell command line from MySQL.
That's good, but that's not the same thing as being at a "command shell" or "command prompt" on the underlying server, which is where you would need to be to install DBT2 or any other utility, and this is not allowed with RDS.
The mysql command line client is, fundamentally, just a tool that allows you to craft queries, issue them to the server, and see the responses. The underlying protocol is exactly the same protocol that your applications use to issue queries and retrieve results from the server. What it can do isn't all that different than connecting with Workbench, Query Browser, Toad, HeidiSQL, or any other graphical MySQL administrative tool. It just isn't graphical.
So far i have 'cd' to directory where files for dbt2 are located.
If you are saying you have 'cd' into a directory on the RDS instance, then, no, you haven't. That's not possible. Perhaps on your local machine, which explains why you are seeing a Windows error message.
C:\Users\Sqlbot>./configure
'.' is not recognized as an internal or external command,
operable program or batch file.
I am a big fan of AWS, a huge fan of MySQL (of course), but not as much of RDS, because I do not generally see being "relieved" of the "burden" of administering my systems as a positive thing, and I don't like the things I am restricted from doing. On the other hand, I am moving forward with plans to migrate some of my production systems to RDS -- but only the systems that with more mundane database requirements, systems which don't leverage some of the more creative things I do with MySQL.
But I don't want my comments to be taken as anti-RDS. I realize that to provide a managed, hosted service like they are doing, they have little choice but to lock things down... I just wish some things weren't locked down quite so tightly. My solution so far is to run MySQL on EC2 and set it up myself, but I digress.
If you are trying to learn to administer MySQL (in depth) and Linux (at all), RDS will severely limit you.
I have done little testing on EC2 instances, but I have done extensive bench-marking of Oracle RDS instances with and without provisioned IOPS.
In my experience the provisioned IOPS deliver close to the advertised performance. Eg. if you provision 1000 IOPS, you will likely peak close to a thousand IOPS with a response time of less than a millisecond, depending on queue depth.
If your workload is I/O-bound then provisioning IOPS may lead to a significant increase in performance.
Note that IOPS provisioning is also available on EBS backed EC2 instances, presumably with comparable performance.
When comparing RDS to EC2 I suppose it mostly comes down to how much control you are willing to give up for the convenience of using RDS over self-managed databases.
Best Answer
You'll have to test it.
You could do some back of the envelope calculations to approximate the number of I/Os per insert, multiply it by the number of transactions per second, add in some buffer room etc, but it's much easier to just test it.
The easiest thing to do is to allocate a best guess, then go back and increase or decrease it to match you're real world testing. This is one of the luxuries of using a cloud based environment, hardware changes are low in capital costs and such changes usually require only config updates. With EBS volumes you can't just increase the number of IOPS, you'd have to scale up the size of the volume as well1. You can always just create a new volume and copy your data over. There will be some downtime but if you're data isn't huge it shouldn't be much as it'd be a raw copy.
Here's a guess at the number of I/Os necessary. Again it's just a guess though as the specifics depend on the number of indexes and whether your traffic flow will be smooth or spikey. At 25K tx/hour you've got ~7 tx/sec. The size of each row isn't particularly relevant as it's less than the size of a single I/O (4K). Each transaction will do somewhere between 1-5 IOP (primary insert plus a couple index tree inserts) so let's say ~35/s.
I say start out with the bare minimum of 100 IOPS and scale up if necessary.