Optimizing Web Applications to Perform Efficiently
Download
Report
Transcript Optimizing Web Applications to Perform Efficiently
SaaS - Performance Management
20th Nov 2013
1
ITaaS Platform
Business Model:
Pre-Integrated suite of HW,
NW, SW and Services
Commercial Model:
Opex based, Build-as-youGrow and Pay-as-you-Use
Configurability:
Meet individual SMB needs
and improve adoption
Business Process:
Embedded best in class
practices for quick start
Pre-built Compliance:
Ensure security and
statutory requirements
Technology Platform:
Leveraging the Cloud for
easy distribution
We studied the business challenges of SMBs to redefine the Technology Consumption
Model
On the software side the solution was to build a set of multi-tenant applications to
leverage the SaaS model
2
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Three tier Architecture
4. Performance optimizations for each tier
5. SaaS Three Tier Architecture
3
ITaaS – Solution Stack
L6
Business Analytics
L5P
Biz Services
L5
Manufacturing
L4
CRM
Software
Solution Layer
Network Solution
Niche Vertical
Application
Hardware Solution
Reward-Recognition
Assessment
Customer Supplier Integration
Layer
Virtual Community
Vertical Core
ApplicationsEducation
Layer
Retail
Wellness
Prof. Services
P&I CommonF&A
HRMS
Payroll
Business Applications
Layer
Online
Enterprise
Messaging
Common
Office
Applications
Layer
Presence Mgmt
Intranet Mgmt
Solution
L3
Document
Mgmt
L2
Network Connectivity
L1
Desktop/Laptops
Network
Devices
Networks
Layer
Projects
Office Mgmt
Solution
Data Center Hosting
Layer
Printers Hardware
On Premise
Servers
All System Software
4
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Three tier Architecture
4. Performance optimizations for each tier
5. Deployment Architecture & Monitoring
5
Performance Challenges
•
Can users get a fast response over the low bandwidth network?
•
Whether to host different solutions on different servers or on the same server?
•
How do we find if anything is slow in production?
•
Can the applications on the cloud scale as transactions and users increase?
•
Will business operations continue in face of a disaster?
•
Will use of Open source tools and servers serve the requirement?
•
How would we avoid bad code entering production?
•
How would we identify if any bad code has entered production?
6
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Basic three tier Architecture
4. Performance optimizations for each tier
5. SaaS Three Tier Architecture
7
Three tier Architecture
Perimeter Security
Web Tier
Internet/MPLS
Reports
Application Tier
Applications
Master
C1
Slave
Database Tier
C1
C2
C2
8
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Basic three tier Architecture
4. Performance optimizations for each tier
•
Web
•
Application
•
Database
5. SaaS Three Tier Architecture
9
Summary
of achieving speed
Introduction
1. Lookup DNS
2. Make TCP Connection
a)
Reduce number of TCP reconnections
3. Negotiate SSL
a)
b)
Make the negotiation quick
Reduce number of renegotiations
4. Send Request
a)
Reduce content to be sent
5. Server Sends Response
a)
b)
Send response quickly
Minimize response
6. Parse Response and Download additional Resources
a)
Minimize number of resources to be downloaded
7. Render Content
a)
b)
Keep content lean, clean and simple
Ensure all required styles for rendering are available at the earliest
8. Compile and execute JavaScript (Single Threaded Blocking)
a)
b)
Keep minimal JavaScript
Defer JavaScript Execution
10
Web tier – Minimize round-trip times
What is a Round-trip time (RTT) = Request time + Response time
Ways to minimize RTT 1.
Minimize the number of requests
•
Avoid bad requests (e.g. 404)
•
Combine external JavaScript
•
Combine external CSS
•
Optimize the order of styles and scripts
•
Use CSS Sprites for images
2.
Parallelize them
•
Parallelize downloads across hostnames (CDN)
11
Web tier – Set HTTP Keep Alive
What is it?
In HTTP/1.1 the keep-alive extension allows persistent
connections . Basically the HTTP sessions allow multiple
requests to reuse the same underlying TCP connection.
Advantage?
Make the
negotiation
quick
Speed up latency for html documents
with
lots of static
content
Example of Web tier setting Apache has 2 directives - KeepAlive and KeepAliveTimeout
These directives keep the connection to the Web server
alive for a pre-defined number of requests or for predefined time period (Default 100, 15 seconds)
Browsers limit the number of parallel downloads to six - eight(per hostname over HTTP/1.1). It
is beneficial to increase the no. of concurrent connections to reduce page load time.
12
Web tier – Optimize SSL Negotiation
1.
2.
3.
Offload SSL Negotiation to a Hardware Device
Enable SSL Session Cache
Set a proper Timeout for SSL Session Cache
Make the negotiation quick
Session Timeout should be a based on the security concerns and normal Session Time of the
user
13
Web tier – Minimize HTML content
Criteria
Object type to use
Example
Records less than 5
Radio button/Check box
Male/ Female
Records rarely increase & is
easy to scroll & choose
Drop down
City, State, Country
• Records increase in a narrow
range
AJAX look up
Clinic names, Site names.
• Limited filters to search
•Records are in thousands and
can increase
•Many filters to search
(AJAX call can be triggered after
certain no. of characters are typed,
esp. in case of Codification)
Use Lookups (popup screen)
Search an item by item id,
item name, store name,
item type, etc
14
Web tier – Pagination
•
•
•
Paginate depending on the context - need not be same for all screens
To reduce navigation show the latest/relevant records first
Leverage various Pagination design patterns
15
Web tier – Filters
• Mandate filters for reports - To narrow the number of records fetched.
• Put appropriate Constraints – Date field should always be constrained.
• A constraint would typically require Functional knowledge
• Set default for certain filters e.g. Status filter defaulted to Open
Note: A file of 3 MB was downloaded with various bandwidths and latencies using
WANEM. (WAN emulator). Please find its outcome and its impact on the end user
experience
Test caseBandwidth
1
114 mbps **
2
128 kbps
3
256 kbps
4
128 kbps
5
256 kbps
Latency
NIL
NIL
NIL
50 ms
50 ms
Time taken
3 secs
3 mins 40 secs
1 min 57 secs
4 mins 45 secs
2 mins
**(without WANEM)
Tools Tip: Create an excel sheet listing all reports names v/s its filters. This would give a holistic view of all
the filters in the solution. It would not be relatively easy to implement policies related to mandating and
constraining filters with some functional knowledge obviously.
16
Web tier – Serve static content
• A typical web request = Static + Dynamic
• Static content - images, style sheets, JavaScript, html, pdf, video files, etc
should be served by Web tier
• Advantage:
1. To avoid use of expensive Application server threads
2. Avoid delay to serve static content during Garbage collections
3. Web servers serve static content faster than Application servers
4. Sets stage for further static content consolidation and scale with use
of CDN
17
Web tier – Minimize round-trip times – Avoid bad requests
HTTP requests are expensive, making an HTTP request and getting a useless
response (i.e. 404 Not Found) is unnecessary. Will slow down the user
experience.
Firefox: Use add-ons like Firebug, Page Speed, YSlow, Fiddler, For IE: Fiddler
18
Web tier – Minimize round-trip times – Optimize order of styles & scripts
Correct order of external style sheets and external/inline scripts enables better
parallelization of downloads and speeds up browser rendering time.
Scenario 1
<head>
<link rel="stylesheet" type="text/css" href="stylesheet1.css" />
<script type="text/javascript" src="scriptfile1.js" />
<script type="text/javascript" src="scriptfile2.js" />
<link rel="stylesheet" type="text/css" href="stylesheet2.css" />
<link rel="stylesheet" type="text/css" href="stylesheet3.css" />
</head>
Scenario 2
<head>
<link rel="stylesheet" type="text/css" href="stylesheet1.css" />
<link rel="stylesheet" type="text/css" href="stylesheet2.css" />
<link rel="stylesheet" type="text/css" href="stylesheet3.css" />
<script type="text/javascript" src="scriptfile1.js" />
<script type="text/javascript" src="scriptfile2.js" />
</head>
Scenario 1 the second two style sheets must wait until the JS files are finished downloading.
Scenario 2 merely by changing the order of the resources - 100 ms is shaved off the total
19
download time.
Web tier – Minimize round-trip times – Combine external Javascripts
Example of the download profile of an HTML file containing requests for 13 different .js files from
the same domain
All files are downloaded serially, and take a total of 4.46 seconds to complete. Now here is the profile for the
same document, with the same 13 files collapsed into 2 files. The same 729 kilobytes now take only 1.87 seconds
to download.
Tip #0 Externalize JavaScript
Tip #1 Deduplicate JavaScript
Tip #1 JavaScript files should be combined into fewer output files (except third party JS libraries)
Tip #2: Serve the file only when that component is requested by a user. 20
Web tier – Minimize round-trip times – Sprite Images
CSS Sprite - A single image file that contains number of different images.
Without Sprite
With Sprite
Reduced 14 HTTP hits as 15 images are combined in one single
sprite improving page load time. Try SpriteMe bookmarklet
21
Web tier – Minify static content
Minification - Removes whitespace, Line Breaks, comments, Shrinks Variables &
Optimizes code in js and css files. Decreases file size & improves page load time.
1.20 MB
1.14
File size
1.00 MB
0.80 MB
0.716
0.60 MB
Payroll JS
0.40 MB
File size
reduction ~62%
0.20 MB
0.00 MB
Before
After
Minimization Minimization
Tools available - Google Closure Compiler, YUI Compressor, JSMIN, Dean Edward’s Packer, DOJO
Compressor.
22
Web tier – Compress static content
1.
2.
3.
GZIP generally reduces the response size by about 70%.
Compression may sometimes not be supported by the proxy setting at customer end
Zipping of images, pdf or any binary file not done as most are already compressed
23
290304000
Web tier – Cache locally to take heat off back-end servers
• Set suitable static content expiry
in the web tier
– Example:
ExpiresActive ON
ExpiresByType text/javascript
"access plus 1 month“
Cache-Control “public maxage=290304000”
• Use a unique identifier to
append every static request, to
refresh browser cache when the
content changes.
Note: Incase of server farms do not use Etags.
24
Web tier – Ajax lookups – Optimization tip
AJAX auto lookups needs to have a limit to the characters entered before which the
lookup is shown. A lookup done for every character entered would lead to executing a
select query. Infact it is directly proportional to the characters typed. Assuming there
is no delay. For SMB we recommend to set it to at least 4 characters.
4 Characters
entered
1 Character
entered
x
Note: Enable Caching of AJAX Requests.
- 25 -
25
Web tier – Bandwidth/Latency & User Experience
Impact on a transaction response time due to Bandwidth, Latency, Browser Cache &
Static file compression in Web tier.
Response times vs. varying bandwidth/latency
Without browser cache
Compression
Bandwidth
Resp. time (secs)
On
Off
On
57 Mbps
(Without
WANem)
57 Mbps
(Without
WANem)
64
Kbps
0.61
0.98
48.38
On
With cache
Off
On
On
On
On
On
128
Kbps
128
Kbps
128Kbps,
Latency
200msec
128Kbps,
Latency
400msec
128
Kbps
57 Mbps
(Without
WANem)
64
kbps
22.89
56.88
44.82
76.09
4.18
0.38
9.81
Note:
Time does not include – Browser rendering or processing
Web Page size: With compression – 260 KB, Without compression – 730 KB
Used TCS' WANem (WAN Emulator)
26
Web tier – Avoid Repetitive Requests
Communicate the system status to the user once a transaction is initiated.
Example:
Use the loader feature which creates a grey transparent layer over the existing User
interface and does not allow the access to the submit button.
27
Web tier – Time to test
Analysis of web service http://www.webtest.org for http://www.tcs.com
28
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Basic three tier Architecture
4. Performance optimizations for each tier
•
Web
•
Application
•
Database
5. SaaS Three Tier Architecture
29
Typical
Activity in the Application Layer
Introduction
1. Read and interpret the request parameters
2. Validate the Request Parameters
a)
Read from Data Store
3. Perform Business Operations
a)
Read from Data Store
4. Persist Data to Data Store
5. Form and Send the HTML Response
Optimize Processing
Minimize fetches from Data Store
Fetch only Required Data
30
App tier – Review default server settings
•
Server Log Level (In thread dumps, several threads in blocked state are observed in several instances where too
many logs at debug, info logs in the code in combination with low log level )
•
Clients/Threads in Web, Application and Database tiers
•
JVM settings
•
Max File Descriptors
Notes: Apache – maxClients, JBoss – maxThreads, MySQL - max_connections
Generally - maxClients > Maxthreads < Max_connections
Every layer works with a limited number of connections and resources (read Threads)
31
Application tier – Memory allocation for JEE Application Server
64bit JVM allows us to set higher values of heap size
But bigger the heap, longer the major GC and hence pause times.
OS: Room for me?
32
Application tier – Out of memory?
Exception in thread “main” java.lang.OutOfMemoryError: PermGen space ?
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space ?
•
•
•
Heap default: java -Xms32m -Xmx128m
Minor GC
Jvisualvm
Jmap
GC Viewer
Major GC
Metadata of
loaded classes
Note: Specific to SUN JVM. Internals may vary depending on choice of JVM
33
Application tier – Exploring jmap (Memory Map) command
Heap Space 1. jmap -heap <PID>
- To get Heap details. Here look at the section named - "PS Old generation" - if its above 8090% we may then execute the next two commands in that order to get more details
2. jmap -histo <PID>
- For each Java class, number of objects, memory size in bytes, and fully qualified class
names are printed. VM internal class names are printed with '*' prefix. This helps to find
who is occupying the heap.
- If the live suboption is specified, only live objects are counted
Note - jmap –histo:live triggers a FULL GC as compared to jmap -histo
3. jmap -dump:live,format=b,file=<jmap_date_server#_dump.bin > <PID>
jmap -dump:format=b,file=<jmap_date_server#_dump.bin > <PID>
Note – Depending on JVM size, the heap dump can be sizeable. To open the heap dump in
IBM Heap analyzer to check leak suspects the overall VM memory required is generally
greater than twice the heap dump size
Permanent Generation Space - jmap –permstat <PID>
Prints class loader wise statistics of permanent generation of Java heap. For each class
loader, its name, liveness, address, parent class loader, and the number and size of classes it
has loaded are printed. In addition, the number and size of interned Strings are printed.
34
Application tier – Scale Out vs Scale up
Methods to add more resources for a particular application fall in two broad categories. Scaleout and Scale-up.
Simple
Complex
Applications designed to scale out will almost always scale up, yet applications designed to
scale up will almost never scale out.
Example - Before development, we would need to think - How do we make the Singletons and
Synchronized code blocks work across processes ?
35
Application tier – Synchronous v/s Asynchronous Communication
Phone call (Synchronous) or vs email (Asynchronous).
Lets look at options to send emails related for alerts, notification, reminder, etc 1) Send email in the same transaction – Synchronous
- Each request blocks the calling thread
2) Send email by spawning a new thread - Asynchronous
- Current thread is not blocked whilst the separate thread awaits a response from SMTP
3) Set a flag to send email and let the batch job do the needful - Asynchronous
- A batch process wakes up after set time –> Checks a status flag – sends emails in configurable
batch mode (i.e. throttle the traffic (count of emails) to be sent (with or without priority) )
Note – Configuration would depend on capacity of SMTP server and/or traffic at that instance.
Also, here optimization techniques like query tuning would be important.
36
Application tier – Server side caching mechanisms
•
In JVM
– Occupies precious JVM heap space
– May trigger early frequent Garbage Collection
– Can slow down and crash system
– Not easy to replicate changes across JVMs in a cluster
•
Out of JVM
– Relatively slower
– Will overcome all the above mentioned problems
37
Application tier – Server side caching mechanisms
1.
Memcached
2.
CouchBase/ Membase (A fork of memcached)
3.
Redis from Google
4.
Infinispan from JBoss
5.
Terracotta (now from Software AG)
6.
Coherence from Oracle
7.
Gemfire from Gemstone
38
Application tier – Use latest stable libraries
Do’s & don’ts
1.
Avoid duplicates jar files
2.
Avoid multiple version of same jar files
3.
Remove unwanted jars
4.
Use latest stable versions of library files
5.
Use Server default Library NOT Application library
39
Application tier – Sticky Sessions
1.
Session Identifies a User
2.
Needs replication in clustered environment
3.
Should NOT be used for storing large data
4.
Session has a time out parameter
5.
Sticky sessions should be enabled
40
Application tier – String concatenation
Method
Purpose
Built-in concatenation
(+) operator
To concatenate static strings
String.concat()
To concatenate two strings
StringBuffer
• Is a synchronized class
String s1 = "aa" + "bb";
• To be used in a multithreaded environment (when
more than one thread access the same StringBuffer
instance).
StringBuilder
(Added in Java 5)
• Identical in all respects to StringBuffer except that is
NOT synchronized, which means that if multiple threads
are accessing it at the same time, there could be trouble
(Not thread safe).
• To be used in places where string concatenation is to
be done by a single thread
41
Application tier – XML Parsing ? Memory is limited
High level differences between DOM parser and SAX Parser in Java:
1) DOM parser loads whole xml document in memory while SAX only loads small part of XML file in
memory.
2) DOM parser is faster than SAX because it access whole XML document in memory.
3) SAX parser in Java is better suitable for large XML file than DOM Parser because it doesn't require
much memory.
4) DOM parser works on Document Object Model while SAX is an event based xml parser.
Thumb rule – Use DOM parser over SAX parser if XML file is small enough and go with SAX parser if
you don’t know size of xml files to be processed or they are large.
42
Application tier – File Handling (Leverage stream-chaining techniques)
FileReader (DataInputStream - deprecated)Common and simple method to read a file but is extremely slow. The reason for the poor performance is that the
DataInputStream class does no buffering. The resulting reads are done one byte at a time.
For e.g. One of the benchmark says that to read a 250 KB file it took 28,198 milliseconds
BufferedReader (BufferedInputStream-deprecated) –
A simple improvement involves buffering the FileInputStream by interposing a BufferedInputStream in the stream
chain. This buffers the data, with the default buffer size of 2048 bytes
Result - The resulting performance increase for the medium sized file (250 kilobytes) was 91%, from 28,198
milliseconds to 2,510 -- over an order of magnitude with just a simple change i.e.
Example try {
BufferedReader in = new BufferedReader(new FileReader(args[i]), 8192);
while ((line = in.readLine()) != null) {
nlines++;
}
} catch (Exception e) {
System.out.println(" BR8192Test: exception:" + e );
}
finally {
in.close();
}
Note - The buffer size used in buffering schemes is important for performance. As a rule of thumb, bigger is
better to a point. Refer - http://www.kegel.com/java/wp-javaio.html. Match the buffer size to the underlying
storage sector size. Adopt similar strategy for writing to files.
43
Application tier – Blocking API - Synchronized
Blocking/Slow API
JVM
Note: In case of Multiple JVM scenario there is no default JVM synchronization
between the Application server instances. Hence, usage of Sync blocks should be
done wisely and at granular level
44
Application tier – Static Code Review
Project Code
Commit Code Commit Code
Jill runs Static Code
review
SVN Server
Central Build Machine
Publish reports
1. Compile
John runs Static Code
review locally
2. Static Code Review
3. Copy Paste instances
4. Design analysis
5. JUnit/Code coverage
45
Application tier – An approach to find time taken by request on each tier
• Use Non-intrusive code weaving (Aspect Oriented Programming
– Available for
• Java
• .Net
– Weave at run time
– Weave at compile time
• Can build all-inclusive monitoring
– Not dependent on any framework
– But can leverage standards like Servlet API, JDBC API etc
46
Application tier – An approach to find time taken by request on each tier
Web Layer
Business Layer
Capture start Time, IP
Address, Port, Request URL
Data Access Layer
SQL, SQL Start Time, SQL End
Time & Request End Time
DB
Capture query
end time
Capture end time
JBoss
1. For each request a unique thread is assigned by the Application server
2. For each thread a Statistic Entity Object is created and its relationship maintained
3. Using Unique thread id retrieve the Statistics Entity object at each layer and fill the respective
attributes
4. Once request is finished calculate time taken to process request, time taken to execute sql
statement for respective URL
5. Convert summary information in to string and stored it in the Collection object.
6. Flush the thread and object relationship
47
7. At periodic interval a service saves the collection object to a log file
Application tier – Fault Isolation Architectural Structure – Swim Lanes
There are four general principles for designing and implementing swim lanes in a system’s
architecture:
1) There must not be any shared hardware or software between lanes other than possibly
highly available network gear such as paired loadbalancers or border routers. (Nothing is
shared)
2) No synchronous calls can take place between swim lanes. If cross swim lane
communication is required, i.e. grabbing search results to display on the same page as login, it
must be done asynchronously. (Nothing crosses a swim lane boundary, Transactions occur along
swim lanes)
3) Limit asynchronous communication. While permitted, more calls lead to a greater chance
of failure propagation.
4) Use timeouts with asynchronous calls. There is no need to tie up the user’s browser or
your server waiting for the eventual TCP timeout.
Note - Swim lane the money maker, Swim lane the problem areas, Swim lane natural barriers
48
SaaS
Performance Management
Introduction
1. The SaaS platform & Solution stack
2. Performance challenges
3. Basic three tier Architecture
4. Performance optimizations for each tier
•
Web
•
Application
•
Database
5. SaaS Three Tier Architecture
49
Database tier – Check for Open database connections
Database memory requirement primarily depends on –
1.
2.
3.
Memory allocated per connection (Limited resource)
Global memory
Memory required for background processes.
To identify connection leaks at various levels
•
Static code review
•
Verify pattern Connect – Query – Quit in dB general logs
•
Consolidate database connection closure code in framework itself
•
Use AOP to find Line of Code that invoked an open database connection or auto
close it
•
Kill any idle connections for more than specified time -Server policy
50
Database tier – Reduce table joins
•
Requirement – To fetch list of all products sold, along with their rate, quantity, sell
date and customer to whom products were sold
•
Typical Join
– Customer Master (100000)
– Product Master (100000)
– Bill Header (100000)
– Bill Details (500000) (Five items per bill)
51
Database tier – Reduce table joins
•
Instead
– Join only Bill Header and Bill Details
– Fetch the Customer Name, and the Product Name from a cache of Hashmaps
• Customer Id – Customer Name
• Product Id – Product Name
52
Database tier – Track slow queries
Select * from emp;
C1
C2
>1 second
Slow Query Log
Optimize queries that:
1. repeatedly run slow
2. examine lot of records
3. fetch lot of records
4. take more time to execute
5. take up locks for long time
Parse & Save in db
53
Database tier – Avoid full table scans
•
•
Full table scans are where the database will read the entire table without
an index.
Reasons why full table scans are performed
–
no WHERE clause
–
no index on any field in WHERE clause
–
poor selectivity on an indexed field
–
too many records meet WHERE conditions
–
using SELECT * FROM
– Generate
function
usedplans
on the
column
in the query
Explain
to indexed
understand
how database
query optimizer
chooses to execute a query
54
Database tier – Consider chunk at a time v/s row at a time
One insert - one connection
ConnectionID_1: INSERT INTO table(A,B) values(1,2);
ConnectionID_1: Quit
ConnectionID_2: INSERT INTO table(A,B) values(3,4);
ConnectionID_2: Quit
All inserts – one connection
ConnectionID_1: INSERT INTO table(A,B) values(1,2);
ConnectionID_1: INSERT INTO table(A,B) values(3,4);
ConnectionID_1: Quit
Batch Insert – one connection
Prepared Inserts – one connection
Good for repeated inserts
Extended Inserts – one connection
Good for bulk Insertion
Batch start
ConnectionID_1: INSERT INTO table(A,B) values(1,2);
ConnectionID_1: INSERT INTO table(A,B) values(3,4);
Batch end
ConnectionID_1: Quit
Begin Transaction
ConnectionID_1: INSERT INTO table(A,B) values(?,?);
Set Value (1, 2); Execute; SetValue(3,4);
Commit Transaction
ConnectionID_1: Quit
ConnectionID_1: INSERT INTO table(A,B) values(1,2),(3,4);
ConnectionID_1: Quit
In case of MySQL extended insert – one connection technique is seen the fastest.
Note: Need to watch out on the limit on size of the query and regular commits
should be done after set frequency to avoid large rollbacks. Use Prepared
Statement and Bulk Commit
55
b
e
t
t
e
r
Database tier – Generate Explain plans
Developer – Query works fast in my environment but is slow in Production,
is something different there?
DBA 1. Records in development environment less than production
2. Optimizer’s perspective matters than yours
Recommendation Generate a Query execution plan to understand the execution plan chosen
by the database optimizer.
An execution plan (Explain plan) helps to understand
• Number of rows examined
• Use of indexes
• Missing indexes
• Type of join
• Information on sorting, etc
56
Database tier – Stored Procedures
Set of SQL statements stored on the server and are pre-compiled. It takes in
certain arguments and processes that code with those arguments at
execution time
Points to ponder before we use Stored Procedures:
1.
2.
3.
4.
5.
6.
7.
8.
Ease to scale database compared to application tier?
Ease to write and maintain?
Ease to debug
Need for specialized skill set
Performance gain
Reduction in traffic between application and database tier
Reusability & transparency
Security
57
Database tier – Use prepared statements
Prepared statements are the ability to set up a statement once, and then execute it
many times with different parameters.
Advantages:
•
Save on query parsing (especially if we execute the query several times)
•
Prepared statement caching inside the J2EE server connection pool avoids repreparing of the statement
•
Cache is database-wide – Improves efficiency across applications if they all use
similar parameterized SQL
58
Database tier – Application tier switch for Database servers
Good Practice For Multi-Tenanted Applications –
Provide an Application level switch that can dynamically select the
database to connect which itself may reside on one more database instances
59
System – File descriptors
Linux limits the number of file descriptors that any one process may open; the
default limits are 1024 per process which generally is not sufficient for
production use
Plan to set this to a value which is more than the maximum number of TCP
connections expected on the server.
60
SaaS
Three Tier Architecture – Consolidate & Scale
Introduction
F5 BIG-IP® Local
Traffic Manager
Web Tier
Internet/MPLS
Reports
Application Tier
Applications
C1
Database Tier
C1
C2
C2
61
SaaS Three Tier Architecture – Consolidate & Scale
Perimeter Security
Web Tier
Internet/MPLS
Application Tier
Reports
Applications
Cloud Capacity
increases to serve
more users and is
resilient to failures
C1
C1
C2
Database Tier
C3
C3
C2
62
C4
C4
SaaS Three Tier Architecture – Caching
Static
Dynamic
Request
Report
Request
Reque
browser cac
Static Use
Request
Dynamic Request
Perimeter Security
Cached Data
Web Tier
Compress Static Content
Internet/MPLS
Reports
Cache-enabled Browser
Application Tier
Server
CE Data
Cached
Cache
Applications
Minified & compressed
Static content served by
Web tier and cached by
browser with appropriate
version
C1
C2
Transactions
Database Tier
C1
Reports
C2
63
SaaS Architecture – Monitoring Production Servers
Performance counters on Production Servers monitored using TCSMonIT
64
SaaS Architecture – Monitoring Remote Machines (On-premise)
Administer from any location
Audit
Home/ Mobile User
Remote Management Server
Internet/MPLS
Monitor
Behind NAT:
Franchisee
Install Software
Experts connect
remotely for
immediate support
LAN: Clinic
Remote backup
Distributed
LAN: Corp HQ
65
SaaS Architecture & Business Continuity
SaaS users
continue to operate
in face of disaster
66