NetSuite Reducing # of Tenants per Shared Host

I can’t tell you how good it was to see a notice pop up when logging into NetSuite telling me we were going to experience some down time. NetSuite was planning to reduce the number of tenants per shared host in an effort to decrease variability of response times. AWESOME! I’d been pestering them about this for several months.

In previous blog posts, I had drawn several conclusions:

  • NetSuite customers share a common host (this was a no-brainer)
  • NetSuite was NOT automatically rearranging tenants to find companies that fit nicely together on the same host.
  • Oracle was pouring money into NetSuite to solve the problem of poor or erratic performance.
  • NetSuite/Oracle was working hard to make it easier to migrate tenants to either a new host or a new data center (and new database architecture)

Here’s what NetSuite/Oracle is fixing. In a multi-tenant environment, different companies all run transactions concurrently. It looks something like this, where each company/customer has transactions arriving at various intervals.

If every transaction arrived at the shared host when it was completely idle, response time would be whatever time it took for the server and database to complete that transaction. But if the shared host is busy when a transaction arrives (and the shared host can’t get to it), it waits for its turn to execute.

The trick is finding the right mix of tenants, possibly companies in different time zones (separated by more than a few hours), to share a host. However, the next problem is the idea of regional data centers. Is it practical to have a company in Ireland sharing a host with a company in California? This would be a great mix. But will the company in Ireland be happy having their NetSuite provision hosted somewhere in the US, or vice versa? Probably not.

So the trick is finding good matches as shared tenants. It appears NetSuite is evaluating this problem and making some strategic Chess moves. I received this notice recently when I logged in.

If you read some of my other blog posts, you’ll see how I was able to diagnose that at least two-thirds of my transactions ran reasonably quickly. One-third didn’t. When I dissected the response times of the poor performers, it was elongated server time (not workflows, and not SuiteScripts) that was causing the problem. It was my conclusion that it was wait times caused by a busy host that was the problem.

So this notice of downtime was truly a sight for sore eyes! I’ve said this before, but it’s worth repeating… Thank you, Mark Hurd (President of Oracle). It appears you are spending your money wisely.