Hey Alex -

It's really rare to test with so many users. Don't get me wrong here, but 1000 concurrent users represents at least a 10K user community (at the very higest end of concurrency rates) . With the concurrency rates we typically see, more like 70-100K users.  Runnning 2K concurrent users would be 500-per on each of your (8 core?) machines.. You'd be be putting somewhere between 2x-3x the load on them you should. You're probably overdoing it here a bit, just saying

Typically, a single load generator (regardless of the tool you use and what software you're banging on) cannot drive "linear load" (I just made that up) indefinitely  - you'll need to stand up additional load generators. While you could increase the amount of RAM given to the VM itself and THEN increase the amount of RAM alotted to the JVM, you're still not going to get good, meaningful numbers - keep in mind that TabJolt itself is "only software" and can only process a certain number of concurrent numbers quickly. If you run the injector on a low-end machine, your results will actually "look bad", and it'll be the low-end machine's fault, not Tableau - it won't be able to process incoming results fast enough (especially failures) and so your TPS will be off.

The basic rule of thumb that I've heard kicked around (no one has every proved it to me) is to use a distnct copy of TabJolt for every 250+ users. What I personally do (I do most of my testing on the cloud) is to use a low-end machine (2-core) for lower numbers of concurrent users), and then for anything over ~150-200 I switch to a 4 core box with much more RAM and give TabJolt more juice in the JVM.

Again, if you're considering running  2K concurrent users as sort of a fun mad science project  - have at it. But at 1000 users you're already going further than most people bother with.

I acutally don't know what --n does. Never tried it! But I'd guess you have to know if the result is going to fail ahead of time for it to be useful, you know?

Cleanup in the postgres database is kinf of a pain in the ***, actually

The high-level info you record for each test goes in a table called test_runs, and then additional data (child records) go in jmeter_data and counter_data. You must delete all the rows in those two child tables associated with the one in test_runs before you can get rid of the test_runs record

If you use the --r ("description") parameter wisely, you can make your life a bit easier. When I'm just playing around, I label my tests something like --r=SMOKE, so I know this is a smoke test I can blow away later...Then, every couple of weeks I'll do this in pgadmin pointed at the PerfResults database:

DELETE from jmeter_data where test_run_id IN (Select id from test_runs WHERE description = 'SMOKE');
DELETE from counter_data where test_run_id IN (Select id from test_runs WHERE description = 'SMOKE');
DELETE from test_runs where description = 'SMOKE';

You have to be pretty careful with this cause you could blow away "good" data. I typically only execute this once I've mad a backup of the database.

edit: Was typing blind above and called the mistakenly caled test_run_id "test_run_in".  Corrected.