I haven't come across any limitation per se protocol, ultimately it all boils down to how the data points (LIFs) are doing and their load and client's kernel capability . What ontap version are you running on FAS3250?
To start with, follow standard troubleshooting steps: ( I am assuming cdot)
1) Begin with finding an overloaded LIF by comparing the number of connections on each LIF. Look for the 'count' on each Node. May be work re-distributing LIFs between Nodes.
::> network connections active show-lifs
::> network connections active show-clients -node <node>
2) What NFS versions being served?
3) Also, if you OCUM/AIUM, just have a look around how the Nodes are doing in terms of processing on different components such as node/aggregate/volume/data-processing etc.
4) From client side : What logs we got, and what errors we see in the /var/log. What is the Client Linux Kernel ? Could it be port-exhaustion ?
https://www.suse.com/support/kb/doc/?id=000017508
This will give you some basic idea around the connections/latency overall and then you may be able to narrow down the cause. There are lots of tracing available in cdot that could help but I wouldn't go that far. If nothing helps, just raise a ticket with NetApp.
Just for reference, this may not apply to your case:
High NFS Latency with multiple connections to node LIFs from common client TCP socket
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Systems/FAS_Systems/High_NFS_Latency_with_multiple_connections_to_node_LIFs_from_common_...
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/NFSv4.1_client_Read%2F%2FWrite_operation_may_be_slow_or_hang_when_pNFS...
