You don't need to setup 1 modem per user. You just need enough lines to handle the concurrent traffic. So if you only have at max 3 fax operations going on at a time, you only need 3 fax modems and a 4-port multi-modem card will handle that traffic.
We setup a solution supporting about 300 users. The server is RedHat Linux running Hylafax with a Perle 4 port multi-modem card. We then have our phone system set to convert the DID number (in our case, the last for digits of the phone number) to the CallerID information. Then on Hylafax side, we have a configuration that links the CallerID to an email address.
So remote person dials 1-123-456-7890, that is set to a pool that balances to one of the 4 lines, the callerID information gets set to 7890, hylafax answers the modem, converts the fax TIFF to a PDF and emails it to the address associated with 7890. This solution also allows outbound faxing from the desktop using HylaFSP on our Windows workstations.
I am not a phone person, so I am a little sketchy on the details of the magic that happens at the phone level, but hopefully what I have posted is enough to get you in the right direction.
Ultimately, you need to know what the server is doing when the problem is apparent, and what the server is doing when all is OK.
Other than saying the network is going slow, you don't really give any clues as to how the server is responding.
When you say that the network is going slow, do you mean that the client application is running slowly, talking to the server, or do you really mean that packet responses are taking a long time?
My action plan would be:
- Confirm that the server's hardware is OK. If you have the ProLiant Support Pack (PSP) installed, browse to https://yourservername:2381 (you have this installed, right?). Logon using an account with admin privs and check the state of your hardware
- Check the configuration of your network card(s). See what sort of round-trip latency you have between server/client (from the client, run ping -t servername).
- Check the event logs (particularly the system log) - run eventvwr.exe
- Check the free-space on your drives. Find out where your paging file(s) are, and how big they are. Consider de-fragmenting your drives.
- Use performance monitor to examine:
a) Physical disk - average disk queue length (want this to be <= 2)
b) Physical disk - % disk time (don't want this to be constantly > 80%)
c) Processor - % processor time (don't want this to be constantly > 80%)
d) Network interface - bytes sent/sec
e) Network interface - bytes recieved/sec
f) Memory - page reads/sec
6) Finally, a bit lower level, but Systems Internals' (now Microsoft's) Process Monitor and Process Explorer tools are fantastic at providing an insight into what's actuall happening on a server
--- 10/09/2012
So, the server is otherwise healthy and responding OK (can remote desktop to it and "use it"). The reason for stressing this point is that Windows Server doesn't handle kernel resource starvation too well. Linux starts killing processes when the kernel is threatened, but MS haven't cottoned onto this idea yet. When kernel resources are maxed out (non-paged pools, Etc), Windows servers can just stop responding... until something frees up a kernel memory resource. Not having a sufficiently large paging file (or files) can expedite resource starvation on busy servers. My next steps would be:
- Check SQL counters in perfmon (as Hennes suggests)
- See how SQL is responding on the server when you are experiencing problems (can you perform basic queries from SQL Management studio?)
- Check the configuration of your SQL server (memory and CPU parameters)
Best Answer
Faxing is, unfortunately, slow - between 14.4kilobits/second and 33.6kilobits/second is the standard for faxing these days. And of course a complex page is going to require more data to be sent than a simple page, hence why you are seeing the difference between plain text and images.
I don't think you are going to see much improvement over that.