How the blocks are filling during the network stress?

Thank you so much for the information you provided. You mentioned some very interesting points. I apologize for the delay in response, as I needed to recheck my results and my code based on your information. As you mentioned, the ‘goal clerk rawsend -Nf mytxns.dat’ command will be much faster than the method I was using. Because of that, I faced a 5-second delay in sending all the 80,000 transactions to goal and submitting them. However, I believe that after the 5-second delay (the delay of signing, sending to goal, and submission), all the transactions were received by the first node in the network, correct? So, the method you mentioned can only improve the delay to less than 5 seconds. But the delay I faced was much more than 5 seconds; for some transactions, it took 84 seconds from the time I received the transaction submission confirmation until block inclusion.

The other point is that, as you mentioned, the transactions were sent very sequentially. However, upon checking block explorers, I found that some of the first created transactions were confirmed very late.

Overall, the main question on my mind is mostly about the transaction confirmation time, not just filling the blocks. Why would it take more than 1 minute for some transactions to be confirmed and included in one block? In this regard, I believe that not filling the block is key to answering that question. After exploring all the results, my current assumption is that the gossip protocol is not working fast enough to synchronize all the nodes and broadcast all the pending transactions to all the nodes. I look forward to hearing from you if you have any ideas in this regard.

Yes, as you mentioned, the testnet may not perform as well as the mainnet, but it is the best representation we have.

The data you provided on the largest block is very helpful for my research. I really appreciate it!

Thank you again, and I look forward to learning more from you in this regard.