We are currently testing running SSIS processes on a single test server, with all resources contained within the server (i.e. no data sources on network etc), about 30 minutes in, I started seeing a lot of network activity via perfmon - and on further investigation (Management Data Warehouse reports), the main wait process on the server is being attributed to ASYNC_NETWORK_IO. The developer is using LOCALHOST as the network connection, which may explain why it would be routing via named pipes or TCP/IP rather than shared memory protocol.
I'm seeing differing views to this online, this (http://www.slideshare.net/Confio/async-networkio) source suggests you can tune the server to use shared memory - however, other sources suggest it is the data backlog between SQL and the application layer (in this case SSIS) (http://mssqlwiki.com/sqlwiki/sql-performance/async_network_io-or-network_io/), with the backlog delaying the SSIS acknowledgement back to SQL to send more data from the bulk import.
The developer tells me he has limited the "rows per batch" setting to comply with running under 4GB (we were previously running in 32-bit); however, now that we run in 64-bit it seems counter-intuitive to reduce the batch row amount, now that SSIS can access all the available memory - is something else going on here? Or should i reduce the "rows per batch" until it streams with causing wait times.