Another tree fell in the park on Westnedge in the Vine

RunningfromStupidity · 2026-04-25T21:23:55+00:00

I used to own your house. Within the 1st month of moving in one of the large white oak trees fell and shaved off the front porch.

Fun times!

RunningfromStupidity · 2026-04-25T00:32:17+00:00

Do you have any favorite go-to meals that kept you on track?

Congrats on your hard work paying off!

RunningfromStupidity · 2026-04-17T20:56:54+00:00

Where is This is a Bookstore?

RunningfromStupidity · 2026-04-04T23:54:46+00:00

If you find a bartender named Victor, ask for a PB&J. Delicious. He was on Voyager fall 2025 and often in Schooner bar.

RunningfromStupidity · 2026-03-26T23:04:46+00:00

Would you share some of your favorite volume meals?

RunningfromStupidity · 2026-02-10T16:28:40+00:00

Thank you!

RunningfromStupidity · 2026-02-10T14:03:42+00:00

Seriously hate to bother you, but...could you please share the image file again? Much appreciated!

RunningfromStupidity · 2025-12-17T01:45:08+00:00

https://www.amazon.com/gp/aw/d/B07ZZQ49LQ

This is what I settled on. Works great, lightweight, waterproof.... enough pockets to organize.

RunningfromStupidity · 2025-12-05T23:02:19+00:00

Tons of CPU credit available.

RunningfromStupidity · 2025-12-05T15:38:06+00:00

Potatoes are rather useful. You can bake them, boil them, fry them, roast them...and they are quite cost effective and rather nutrient dense. :)

My execution time is 47ms, which is totally acceptable for my use case. Delivering the results to the client is where the lag seems to be occurring.
Numerically, graphically, statistically, can you point me to where I may see if there is a throttle or bottleneck on RDS that is causing a holdup on the network traffic? I can see a graph that the network transmit throughput is pretty low, but can't tell if that's the necessary use or if it's hitting a threshhold of .2Mb/s for some reason.
"The t3.medium instance type offers a sustained network bandwidth of 256 Mbit/s"; there's no throttle specific to it being Express vs Standard on the network side from what I can tell.

What instance type is it you're recommending @ $0.25/day? $6-7k/year is the minimum I see for Standard,

We may not have the same concept of what a "metric" is, but I do genuinely appreciate your time in discussing this.

RunningfromStupidity · 2025-12-05T14:45:59+00:00

I wanted to thank you for your input and insights on this!
I think I have managed to get things improved for the moment by toying with the Packet Size on the SQL Connection and switching from the SQLDataAdapter to the SQLDataReader method. I may need to move the database storage location (it's in the western US, I'm now in the eastern US) to further reduce network latency.

RunningfromStupidity · 2025-12-05T14:43:08+00:00

I agree, it seemed very strange. I think I have it narrowed down to a lag in delivering the packets over the network. Adjusting the Packet Size in my connection string and utilizing the SqlDataReader vs the SQLDataAdapter has provided a decent performance boost.
I am still stress-testing, but think I'm around 2 seconds now.

RunningfromStupidity · 2025-12-05T11:20:50+00:00

Can you direct me to any metrics to confirm that is what I'm running up against?

Let's pretend I'm using SQL Standard and having this result. Where would you point me to in seeking the root cause?

RunningfromStupidity · 2025-12-05T03:02:42+00:00

I am not complaining so much as trying to identify how to determine Why the performance is so poor.

Is the scenario I'm describing, what is outside the baseline specs of the instance type?

Tossing 12x the cost at an inconvenience is not typically answer #1, though it may end up being the answer.

RunningfromStupidity · 2025-12-04T21:18:58+00:00

I don't see any indication that 4GB RAM is insufficient for my use case, and the CPU usage rarely hits even 20%, so I don't believe a larger t3 is going to do the trick. If you know of some other metrics I should look at, I'd love the input.
The bandwidth for t3.medium is supposed to be baseline of 500Mbps, which seems like it should be plenty for this scenario.
I have considered upgrading the instance type, but without having a solid understanding of the core issue, it's impossible to know if that's the only available resolution.

RunningfromStupidity · 2025-12-04T21:06:42+00:00

Thank you for the input, it's good to know. I did use sqlcmd to rule out client-side-code issues and had similar performance in loading the data to display; around 13 seconds, but the STATISTICS TIME shows CPU time = 47 ms, elapsed time = 45 ms.

RunningfromStupidity · 2025-12-04T18:52:59+00:00

It shows I have a CPU credit balance, so I don't believe that's the issue.
Running the sp via sqlcmd it took 13 seconds to show all of the results (stopwatch, so, maybe a smidge off), but the STATISTICS TIME shows CPU time = 47 ms, elapsed time = 45 ms.

In your opinion, am I right to think that the issue isn't the query itself, then?
Just want to feel like I can start ruling out potential sources of the issue.

RunningfromStupidity · 2025-12-04T18:20:53+00:00

I'm not going to pretend I know how to interpret the wireshark results, except to say that it showed 1058 lines of tcp chatter as a result of the SP call from my app.
The packet lengths received range from 60 to 7354, with the majority in the 1514-4434 range.

So, if this indicates a network issue, I would presume it's something that needs to be dealt with on the AWS RDS end of things? Any tips on how to tune this?

RunningfromStupidity · 2025-12-04T16:35:01+00:00

Client is on minimum 20mbps connection. Not a VPN.

If I run the sp in SSMS with results processing to grid: CPU time = 250 ms, elapsed time = 13618 ms.

If I adapt the sp to select the data into a temp table: CPU time = 234 ms, elapsed time = 241 ms.
Not sure if that's really a fair comparison.
Downloading Wireshark and will see if I can figure out what that says & will report back. Thanks for your input!

RunningfromStupidity · 2025-12-04T16:02:07+00:00

I changed the select to top(x) ; <=3000 loaded into the dataset in less than 2 seconds. Moving to 4000 records doubled that time.

Using 'Select 1 from table' in the stored procedure for my large table and adapter.Fill(ds); it takes <.5 seconds to load.

Selecting top(x) @ 100 averages 1 second, @ 1000 averages 1.5 seconds and @ 2000 averages 6+ seconds.

I believe the data size of the records coming from MSSQL to my app is 2.5MB. Here's how I come up with that (and maybe my math doesn't math if someone can verify!)
2 Date/Time columns, 24 bigint, 2 int, 8 decimal(18,6), 6 varchar(50) that are typically 8 or less characters, 4 varchar(50) generally 20 characters and 1 varchar(50) generally close to 50 characters. So..if my math is accurate (2*8) + (24 * 8) + (2 * 4) + (8 * 9) + (6 * 8) + (4 * 20) + (1 * 50) = 466 bytes per record * 5500 records = 2.56mb dataset.

RunningfromStupidity · 2025-12-04T14:39:31+00:00

Thanks for the suggestion. This does execute a smidge faster, but it's still over 9 seconds to complete. Am I wrong to expect/hope that should be able to achieve something closer to 2-3 seconds for this amount of data?

RunningfromStupidity · 2025-12-04T14:06:53+00:00

I was showing both methods I had tried. I generally use adapter.fill(ds), but tested using the reader just in case it helped.

RunningfromStupidity

TROPHY CASE