@eldorado, With data and indexer on same node, was the index resident 100% in memory? If the index is not 100% resident in memory, then we can not expect the build time to be equal to the case where index is 100% resident in memory. Also, with one node having all services, we need not use partitioned index. Because, all partitions resides on same node.
The index with hash(meta().id) is the correct way to use the index as partition by clause requires immutable fields. Also, when index is build with hash(meta().id), it would transmit less data over the network compared to partition by hash(11 fields) and the index build would be faster if network is a bottleneck.
For tracing the network utilisations, I am not expert in this area but you can start with the iperf command line utility to measure the intra node bandwidth. This will give us the max rate at which data can be transferred between the nodes. In our perf cluster, our intra node bandwidth is set up at 10Gbps. We want to understand this value in your case.
Additionally, you can capture the output of “cat /proc/net/dev” before and after the index build. This will give the data that has been transmitted during the index build phase. This value coupled with the network bandwidth can tell us if network is being a bottleneck or not. I am not sure if there is a more easier way to do this. I will let you know if I find any.
Thanks,
Varun