Cisco – How to control WAN Download Bandwith on an ASA

You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.

If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.

If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.

If you want to try your luck with deeper buffers, something like this should suffice:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.

The short answer is no.  Your queuing policy needs to be applied outbound at the point of bottleneck.  In this case, the bottleneck is the WAN connection (20 Mbps) between the pfSense and the 1841.  Thus, the proper location of your queuing policies are outbound on the LAN interface (a bit of a misnomer) of the pfSense and outbound on Fa0/01 of the 1841, which you have.

All that being said, your policy on the 1841 is flawed.  In your example, you've reserved 1 Mbps of bandwidth for VoIP and applied the policy to a 100 Mbps interface.  What happens when the PCs start pushing 70Mbps of traffic while trying to make a VoIP call?  From a queuing standpoint on the 1841, the answer is nothing.  There is only 70 Mbps of data flowing out Fa0/1.  Therefore, there is always 1 Mbps available for VoIP.  However, once this traffic reaches the pfSense,  at least 50 Mbps of data and VoIP will be dropped.  Your calls would be terrible at best.

Without getting into all of the details, and using your prior example, the policy should be something like this:

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145
!
policy-map PM-PRIORITISE-VOICE-child
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map Shape-20Mb-parent
 class class-default
  shape average 20000000
  service-policy PM-PRIORITISE-VOICE-child
!
interface FastEthernet0/1
 service-policy output Shape-20Mb-parent
!
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

This policy creates an artificial bandwidth limit on all traffic leaving the Fa0/1 on the 1841.  Thus, the pfSense will never have the opportunity to drop traffic indiscriminately.  Also, instead of the bandwidth command, the priority command should be used to limit latency and jitter.  The tagging and the ACL change should be self-explanatory.