There are some situations where the system performances are not the desired ones.
If you think you have performance problems, we recommend that you follow one of the guides
Possible causes of low performance:
- Insufficient hardware
- Hardware / Driver Thuning Required (NIC driver optimization)
- Duplex Mismatch
- Traffic Shaping
- MTU problems
- WAN connection
- Client/Test methods
- ISP problems
This is the most frequent cause of perfermances problems. It is essential to understand if the hardware we have available is able to withstand the workload for which it was installed.
First check this link if the sizing was done correctly or the ardware is obviously undersized.
If the sizing is adequate, it will be necessary to switch to more refined verification tools to identify the problem.
The most obvious thing to do is to check the vital parameters of the machine, such as: CPU load, RAM load and any swapping during the traffic peaks.
To do this you can proceed in 3 ways:
- Check on the Dashboard – System Information: check the CPU usage, Memory usage, SWAP usage parameters
- We can then check the details of the CPU load during load peaks to see which process the CPU is saturating. The path to follow is: Diagnostics> System Activity
- Enter the console (also via ssh) and execute the command: top -aSH
If you observe an IRQ (interrupts) process for the network card, then the hardware you are using may be almost or completely saturated, or the NIC driver may need to be optimized. If the system is not under stress during data transfer, the problem probably lies elsewhere.
If the CPU load is high and the amount of interrupt is low, the problem may be in the amount of processing of the packages processed by pf or used for cryptography.
If one of the CPUs is saturated, then the bottleneck will be the processing of the pf packets. We recommend using a CPU with a higher clocked core, as one of the pfSense® CE 2.1 files is just that some demons like pf use only one CPU.
In version 2.2 and later, pf is able to use multiple cores.
If the limits on the CPU are found due to encryption you can always choose a system with cryptographic processor.
Hardware/Driver Thuning Required (NIC driver optimization)
If, when viewing the job list with the TOP command, you notice that one of the CPUs is entirely occupied by interupt (IRQ) then it may be necessary to optimize the driver.
To do this follow the guide: Optimizing and troubleshooting network cards.
Some network adapters such as IGBs (Intel Chipset) are able to use multiple queues and distribute traffic across multiple cores, thus achieving greater throughput.
Another element to check is in System> Advanced and finally Networking tab. Make sure the boxes to disable TSO and LRO are fleggate. If they are already flegged, try turning on the checksum offloading option. If no differences are observed, set everything as before.
On 100Mbit / s networks or less, a duplex mismatch is possible. Some producers are stuck in the stone age and still insist on hard-coding ports on CPE, such as full-duplex 100Mbit / s fiber converters.
If the CPE is hard-coded, but the firewall is not, you will need to check the duplex on Status> Interfaces. The duplex mismatch will lead to interface errors, collisions, and low speed. The NIC speed and duplex setting is described in this guide: Force Interface Speed or DupleX Settings.
If the traffic shaping wizard was performed before an increase in bandwidth, the bandwidth limits set previously may still be in effect. Visit: Firewall> Traffic Shaper and check the rules set are still valid.
Also check the Limiters tab under the traffic shaper settings, check that any limiters are set for the appropriate speeds.
Problems relating to upload speed often end up being MTU-related problems. If the MTU on the pfSense® CE device (default 1500), is higher than the MTU of the uplink, it can result in packets that are fragmented or lost. Setting MSS clamping on WANs or changing the MTU of the interface can help.
There may also be problems between the WAN and the modem/CPE. It could be a cable, or “an anomaly” in the way the two interfaces talk to each other. Put a small switch between the firewall and the modem/CPE as a test.
Slowness can not always depend on the device hosting pfSense. It could be the client himself or the way he connects.
Always make sure that the devices with which and from which you carry out the tests are not the cause of the problem.
Ensure that the client is connected to the firewall via a fast connection, at least like the WAN.
If any other factor has been deleted, try the modem without the firewall. If the speed is still low, the provider may be the cause of slowness, or the modem / CPE.
The original document is here.