Do you have access to the folder where backups are happening on the live system? If so, restore the live database onto your test box and run some tests that way.
If you don't have access to where the backups are stored, are you able to run a full backup (I recommend copy only) on the system and dump it to a location you do have access to?
If you can't do either of those, then things may get more interesting, but hey - you are off the hook for disaster recovery!
Without access to the backups, you could look something like SSIS to move the data across, but it is going to be on a table by table basis. I would strongly encourage you to get a backup restored of the live system so you can do real-world testing.
Alternately, you could grab a publicly available database backup like Adventureworks or any of these ones:
and then you have a database to work with. Next, look for some data that you can JOIN and do some calculations on (SUM, COUNT, AVG, etc) and then sort the data on a non-indexed column. The reason I recommend all of that is then you are making SQL do some work and the query will take a little bit of time to complete. Depending on your server and what you joined, you may still have really good performance. But even if performance is really good, that isn't that big of a deal. Turn STATISTICS TIME ON and get some baseline runs. Then turn on SSL and repeat. I expect the timing is going to be NEARLY the same. Your connection time is where things might be a tad slower, but even then I doubt that anybody would even notice the difference.
If you can get your real database, you can have the added benefit of seeing the performance difference between your LIVE system and your test system too. If it runs in 2 seconds on LIVE but 4 seconds on test, and 4.01 seconds on test with SSL, live will run in roughly 2.005 seconds. I say roughly because it is rare for things to be linear like that with SQL and computers. It could be that your test with SSL runs faster than test due to other processes using less CPU/RAM. It could be that test with SSL runs slower because the disk presented to it by the SAN is a spinning disk that is shared with some other system. That is why in my original post I recommend running the query multiple times to get a good baseline. Even first run (and depending on your configuration, second run) will be slower than the future runs due to SQL needing to build up a plan. Plus, if the table hasn't been queried before, the pages may be on disk instead of in memory which can change performance. So I recommend a MINIMUM of 3 runs (1 to get the plan into memory, 2 in case you have optimize for ad-hoc queries enabled, and 3 to get the result once things are properly cached), but more is still good. When I do testing like that, I run it until I get fairly consistent results. if it runs in 2753 ms the first time and 2626 the second and 2686 ms the third and 2698 ms the forth and 2778 ms the 5th (note these are nearly actual values that I pulled while re-running a query on my system. I added 2000 to each of them), I can see that it ranges from roughly 2.62 seconds to 2.75 seconds for my run time with an outlier of 2778 on the 5th run. Since the majority of them are around 2.7, I'd say it is 2.7 for my run time with a query like that one. Now if I check the CPU time, that value in my case is higher which MAY seem strange. In my case the ACTUAL line that statistics time brought out was:
SQL Server Execution Times:
CPU time = 9579 ms, elapsed time = 725 ms.
So you may be thinking "hold up... CPU time was nearly 10 seconds, but the elapsed time was under 1. How does that make sense?" and that is due to parallelism. This query went parallel and broke itself up across all of my cores. So hypothetically, if it took 10 seconds of CPU time on 10 cores, that is 1 second per core. In my case, I have 16 cores so it is taking roughly 600 ms per core. If I remove the parallelism on it, the whole query completes in 5 seconds and my CPU time and elapsed time are nearly the same with elapsed being slightly higher than CPU (which is expected).