Nothing makes me more angry than getting charged for software that is stupid and only uses one core/CPU/thread.

If you look at the various white paper discussions and testing of ESRi’s server products, it scales VERY poorly on more sockets and cores. As someone else mentioned with SQL server if you add another core you can see double the performance….not so with ESRI.

For my department, the question of cores was a critical point in whether we stayed with Oracle for a key information system upgrade or moved to SQL Server. With SQL Server, we could expect almost double the processing power (could have been more if we’d gone with 8-core processors) for a lower price. Hard to argue against those numbers.

I guess I don’t have any right to complain though. ESRI is a privately held company and is free to make its own business decisions. As are its customers.

I mean, to a degree I don’t necessarily “mind” maintenance fees as long as I get something for it and they arn’t too stiff. But to purchase a piece of software, and then be told that the cost of that software depends on what kind of hardware I run it on is pain. That’s like trying to charge for how potentially useful a product might be to your organization. If you really need it, then we’ll charge you through the nose!

I’ve had multiple folks tell me that ESRI is looking at addressing the Virtual Server issue in regards to licensing. I’d assume it would be figured out by the Dev Summit (but that is my guess).

What I’d like to see from ESRI is a definitive statement on what licensing would be required to run ArcGIS Server in a VMware instance limited to a number of virtual cores that is less than the number of physical cores in the server.

Example: ArcGIS Server in a VMware virtual machine restricted to 4 cores (equivalent to the current licensing of two sockets of two cores each) on a physical server with a total of 8 cores.

Quad core processors are no longer rare in servers, and it would seem fair to licence the software on the number of cores it can actually use.

Usage-based licensing (where the user is charged for actual use rather than potential use) makes a lot more sense, and scales regardless of hardware changes.

Of course, what makes the most sense of all is to use software that does not require licensing fees

Yeah–with server software, it’d be nice if some kind of floating license scheme could be achieved. Or maybe some kind of metric-based approach, like with fractional leased-lines and certain colo services.

Unfortunately, I for one would not like to have such monitoring on my server to accurately measure that kind of utilization. I suspect many other people would feel the same way or are under legal requirements that would forbid it.

Should you pay for the most something could ever use, even when that use is divided into time slices? I wouldn’t.

You never actually run on a fraction of a processor and depending on allocation of processors by ESX you will never consume more than that. Yes, memory and network resources can be over allocated and increased in times of contention but processor is not.

If you allocate four processors to a server than that is the most it will ever use.

The gist was: how is pricing by core going to work in a virtualization environment? (ESX Server running on a blade server, etc.) You could have a whole OS that is running on less than a core, and then could jump up to using tons of resources when a big job comes through.

It’s hard to price server software.

Ok, I don’t really feel that way. But it’s a good question. Even if they don’t officially support it, it’s still something people will try.