In this case, QueryDatabaseTable is fetching all the rows (5000 at a time from the DB, but only one query), and sending them out one at a time. To avoid the Connection reset error, try setting a Validation Query on your DBCPConnectionPool, perhaps "SELECT 1 FROM DUAL".
The reason GenerateTableFetch is slower is because it will do a separate query (based on OFFSET/LIMIT) to grab 5000 rows each time. This is much slower as the DB will have to handle many more queries (using offsets & limits), instead of a single one. Also it appears you only have a single ExecuteSQL instance, you can make this more concurrent by setting Max Concurrent Tasks on the ExecuteSQL processor to something higher. Having said that, GenerateTableFetch was designed such that the queries can run in parallel, meaning you can distribute the SQL flow files among a NiFi cluster, and each node would have an ExecuteSQL that could perform the queries. On a single NiFi instance, GenerateTableFetch doesn't get you any improvements in performance; in those cases it's usually only necessary if you need to pass incoming flow files to GTF, since QueryDatabaseTable doesn't accept inputs.
You also don't need the ExtractText to get the SQL content into an attribute: if you leave the "SQL select query" property empty, it will assume the SQL is in the content of the flow file.
I guess the bottom line is that for your use case, I agree QueryDatabaseTable is the way to go, hopefully the Validation Query will get the issue cleared up so you can continue.
