Multi-tenant Database Performance Tests Results - Litwarehr

8/14/2019 Multi-tenant Database Performance Tests Results - Litwarehr

http://slidepdf.com/reader/full/multi-tenant-database-performance-tests-results-litwarehr 1/28

Performance Testing

Results



Lab Configuration

SQL Server 2005

HP Proliant DL 385 G12 32 Bits Processors (1.8Ghz)4 GB Memory4 spindles SCSI 10000RPM



Extensibility Patterns• Extension Table

• Fixed Columns



Extension Table• Shared table

with schema

common to alltenants

• Shared

extension tablethat containsone row for

each field



SELECT

OPERATIONS

Extension Table



Extension Table – View(one join per table)

Sharedfields

Custom fieldsA view is createdfor each tenant



Test• Retrieve a random page of records from arandom tenant view

SELECT *, ROW_NUMBER() OVER (ORDER BY Id) asRowNumberFROM entity_tenant(x)WHERE RowNumber >= (#y) and RowNumber <= (#z)

Notes: (#y) and (#z) are random values based on the

number of recordsPage Size = (#z) - (#y)

Randomization



How Does it Scale?

9 Extension Fields



Analysis• With more tenants and rows in the

database, as the number of

concurrent users increases, theretrieval of randomized rows causesmemory pressure and consequently

I/O activity due to paging.

• Let’s validate this behavior by

looking at the next chart…



How Does it Scale?

Tx/sec, CPU use and memory (with side effect of I/O activity)

25 concurrentusers

Memorypressure

&I/O Activity

No relevantI/O Activity



Measuring the effect of adding fields

25 concurrentusers

Increasing the number of fields impacts on theoverall throughput anorder of magnitude

While increasing thenumber of tenants and

rows per tenant does notimpact in the same way



Test• Retrieve rows filtered by a random field

value from a random tenant view

SELECT * FROM entity_tenant(x)WHERE field(n) = ‘value’



How Does it Scale?

The behavior remainssimilar

GetOne(filteri

ng)

GetAll(no

filtering)



Conclusions• Filtering by a value in the extension

table has little effect on the overall

performance• It’s expected an increase of the

processor usage due to the row

filtering. This becomes evident in the0 fields scenario



Extension Table – View( using PIVOT )

Create a view foreach tenant

Transpose theresults



Comparing to PIVOT

Current query

PIVOT query

New SQL 2005 feature, PIVOT,has lower throughput than

the regular approach.CPU and I/O Usage remains

similar

The slope of the PIVOT approachseems to be better compared tothe current query, however 20fields is already an edge case



To keep in mind• Indexes help!

– Clustered Index on “tenant id and record

id” – Clustered Index on “record id and

extension id”



INSERT

OPERATIONS

Extension Table



Test• Get Entity Schema from

TenantMetaDataStore DB (retrieves

entity fields definition)• Insert Shared Data in TenantDataStoreDB

• Insert Custom Data in TenantDataStore

DB



The effect on Tx/sec and CPU usage

5 extension

fields

As we addconcurrent users,

throughput increasesin a healthy way

DataFile LogFile

Relevant forinserts

Metadata (3000 tenantsand 10 fields or more)is causing memorypressure and

consequently I/OActivity

Next Steps:

Analyze how toimprove Metadata

Retrieval



Conclusions• At 500,000 rows (100 tenants)

– Throughput increases with the number of concurrent users. Resources remain inacceptable levels.

• At 15,000,000 rows (3000 tenants) – Minimal gain in throughput due to memory

pressure and consequently intensive I/Oactivity (page file).• Next Steps: Analyze how to improve

metadata retrieval

• Analysis hints: – “Writes” use sequential I/O for log files, “Reads” involve



Fixed Columns

There is a preset number of customfields in every table you wish to allow

tenants to extend



Testing Approach

• Testing performance for the fixedcolumns approach works against a

single, fixed-schema table• This is analogous to the extension

table approach but without extension

fields (no extension field table)



SELECT

OPERATIONS

Fixed Columns



Fixed ColumnsFixed Columns

approach scalesbetter than

extension tableeven with a large

number of

tenants

Response time isnot affected by

concurrency



Analysis

• Fixed Columns approach(analogous to 0 extension fields)

scales better than extensiontable – Extension table is CPU intensive when

adding fields (98% vs. 35%)

• When adding concurrent users, wegain throughput while response timeis not affected

•

Memory remains the same



Bottom Line

• Developing multi-tenantarchitectures requires stressing the

database to detect the glass ceilingof customers you can handle in asingle instance. This involves:

–

Developing unit and load tests foreach scenario

– Generating a massive set of simulated data

– Deploying the tests in a rig and



Introducing the Multi-tenant

Database Performance TestGuide

Documents

Multi-tenant Database Performance Tests Results - Litwarehr