-
Yes, Untangle is highly threaded. Which means it needs to be able to process as many threads simultaneously as possible.
The clock speed can be rather low, if it can have multiple threads running at once. Think of each thread in terms of simultaneous AV scans.
What's faster? Lining up all those AV scans on 1 super proc? Or queuing them up in multiple slower lines? The latter is the reason why we have multi-core, and Untangle is one of the few products that gets an extreme boost.
And the fact that it has a SQL server in it... only adds more to this idea.
-
Another thing to consider is that let's say you only have 4 cores in your ESX host. Also, lets say you have a 4-vCpu guest, and a 2-vCpu guest. These guests would MAJORLY suffer. This is because, correct me if I am wrong here, ESX will not execute the threads for the 4-vCpu guest until all 4 host cores are ready at the same time. So if the 2-vCpu guest was really busy, the 4-vCpu guest could be waiting a long while. When if you just configured everything for 1vCpu, there would never be any waiting ever.
-
If that is indeed the way VMWare does the CPU sharing, that would explain several strange load situations I've bumped into over the last year.
I just "reserve" the CPU resource I need for Untangle. It's a VoIP server, it isn't good to virtualize. But, having it in an virtual environment has value. So I don't support UT inside any VM environment unless there is enough resources dedicated to the UT VM.
