6

A vendor is stating that their software requires Windows Server 2003/2008 versus Windows 7 Professional because it doesn't perform well on a non-server OS. The specific reasoning was that the number of network connections is limited on Windows 7 Pro. I have 10 client workstations and the maximum number of peer-to-peer connections on Windows 7 Pro is 20 (according to some random post I found on the web).

The application doesn't deal with domains, doesn't use IIS, Exchange, or other server software. The executable resides on the "server" machine and clients use a peer-to-peer connection (mapped drive) to connect to the server and run the executable (think \servername\folder\program.exe).

The hardware requirements state that a Core2Duo or better processor is recommended as well as 8 GB of RAM. I have a i7 processor with 12 GB of RAM, but am running Windows 7 Pro (which they don't support).

What would be some reasons that could cause poor performance when the program is hosted on Windows 7 Pro versus Windows Server 2003/2008?

Thanks

EDIT 1: First of all, thanks for the feedback. I know it is against the vendor requirements and don't plan on implementing the program on a workstation OS, but what I really wanted to know was the technical details. What could cause poor performance on a workstation OS versus a server OS when both are running on the same hardware?

Mike
  • 61
  • 3
  • 11
    Not wanting to deal with/support the types of people and businesses that try to run enterprise-grade software on PC-grade gear jumps to mind immediately. Some customers are simply not worth having. – HopelessN00b Aug 15 '12 at 23:30

3 Answers3

7

The limit of 20 concurrent connections applies to SMB connections as well. You're really not thinking scalability if you limit yourself to a max of 20 clients.

The bigger issue is that you wouldn't be following your vendor's requirements. They don't support what you want to do, so don't do it. They likely don't QA it against non-server OSes, so you shouldn't run it on one.

Not to mention that using a workstation to perform a server's function makes systems admins cry.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
4

Technically? This entirely depends on the program's architecture.

Sometimes there is a "real" reason; server OS's are tuned for server tasks rather than desktop tasks. They can be tuned for better network performance over delivering a better desktop experience.

Usually what it comes down to is the vendor doesn't want to support desktop issues. They have a set of systems they test on, and if you put it on something they didn't test, it will probably work just fine. BUT if you DO have trouble, they'll slap the pointer stick at a big poster that specifically states WE DON'T SUPPORT WHAT YOU DID and tell you you're not entitled to support, please stop clogging our tech support lines...

Last thing I think of offhand is licensing. For multiple users you usually need a server license for all your users; desktop workstations aren't licensed for this (depending on the OS.)

What it boils down to is that in most cases it only runs on servers because the vendor tells you to. Not a technical reason. Sometimes there is a real reason for the requirement. The only way to tell is to test it. Most sysadmins frown on this, though.

Bart Silverstrim
  • 31,172
  • 9
  • 67
  • 87
2

I believe the 20 concurrent connection limit is related to windows file sharing. So if it's not using windows filesharing and instead uses ip sockets directly then it should run fine. There may be other limits if the software utilises any services on the machine that are MS specific. But my guess is it'd technically run fine.

The other difference is that windows server tends to be tuned in a way that optimises it for serving things in the background, while desktop OS's like windows 7 are optimised to provide a better user experience.

As mentioned by the others though, the vendor may not want to support their product on anything other than windows server. You may find the installer prevents you from putting in on anything else. Try it and see how far you get.

hookenz
  • 14,472
  • 23
  • 88
  • 143
  • The connection limit is 20 inbound TCP connections – longneck Aug 16 '12 at 01:18
  • No it's not. I'm a developer and write servers that support more simultaneous connections than 20 that run on windows 7. – hookenz Aug 16 '12 at 01:20
  • Sorry, 20 simultaneous TCP connections. If you're running a web server, you might not hit that limit. – longneck Aug 16 '12 at 01:21
  • It does seem like there are some limitations that server versions remove though. – hookenz Aug 16 '12 at 01:27
  • Mostly it's to do with file sharing. See: http://www.windows7hacker.com/index.php/2011/01/how-many-concurrent-connections-allowed-to-access-a-windows-7-computer/ – hookenz Aug 16 '12 at 01:29
  • @Matt: last time I checked, Windows did not actually prevent you from having more than the licensed number of simultaneous TCP connections, but doing so was a violation of the EULA. – Harry Johnston Aug 16 '12 at 02:14
  • Harry - interesting. It's like giving you a car with 5 seats and telling you you're only allowed to carry one other passenger. – hookenz Aug 16 '12 at 02:33
  • Was the limit not HALF OPEN connections or something like that? – TomTom Aug 16 '12 at 04:42
  • TomTom, that was originally 10 half open at a time (on the outbound side) and basically throttled the creation of connections. Apparently it was to help prevent the spread of worm virus'. A dumb idea IMHO. The limit has been completely removed now. – hookenz Aug 16 '12 at 22:29
  • http://www.mydigitallife.info/half-open-outbound-tcp-connections-limit-removed-in-windows-7-and-vista-sp2-no-patch-required/ – hookenz Aug 16 '12 at 22:31
  • Actually, turns out there are still major limitations in the tcp stack. Definitely use server os if you expect to serve lots of people. – hookenz Sep 19 '12 at 02:18