This document discusses database performance core principles and how moving business logic out of the database and into application servers can negatively impact performance. The key points are:
1. Oracle databases are process-based and processes need to get CPU time quickly, stay on the CPU, and experience few involuntary context switches.
2. Moving business logic out of the database and into many small calls results in high call counts, more voluntary sleeps as processes switch contexts, and potential oversubscription of processes leading to involuntary sleeps.
3. This violates database performance principles and leads to inconsistent response times, lower throughput, and inefficient use of computing resources across database and application servers due to increased overhead of switching processes.
Keeping
Java EE 8: What Servlet 4.0 and HTTP/2 mean to youAlex Theedom
The goal of HTTP/2 is to increase the perceived performance of the web browsing experience. This is achieved by multiplexing over TCP and Server Push among other techniques. What implications does this have for developers? How does Servlet 4.0 embrace HTTP/2 and what support is there in JDK 9? We will see, with code examples, what the future of developing with HTTP/2 might look like.
Java EE 8: What Servlet 4 and HTTP2 MeanAlex Theedom
The goal of HTTP/2 is to increase the perceived performance of the web browsing experience. This is achieved by multiplexing over TCP and Server Push among other techniques. What implications does this have for developers? How does Servlet 4.0 embrace HTTP/2? We will see, with code examples, what the future of developing with HTTP/2 might look like.
Java EE 8: What Servlet 4.0 and HTTP/2 mean to youAlex Theedom
The goal of HTTP/2 is to increase the perceived performance of the web browsing experience. This is achieved by multiplexing over TCP and Server Push among other techniques. What implications does this have for developers? How does Servlet 4.0 embrace HTTP/2 and what support is there in JDK 9? We will see, with code examples, what the future of developing with HTTP/2 might look like.
Java EE 8: What Servlet 4 and HTTP2 MeanAlex Theedom
The goal of HTTP/2 is to increase the perceived performance of the web browsing experience. This is achieved by multiplexing over TCP and Server Push among other techniques. What implications does this have for developers? How does Servlet 4.0 embrace HTTP/2? We will see, with code examples, what the future of developing with HTTP/2 might look like.
A modern web browser supports a surprising number of protocols designed for fast, efficient, and secure communication. Even though some goals of these protocols might overlap, their features are different enough to make them all worth our attention. This session focuses on HTTP/2, SSE, and WebSocket. It is based on experience gained during development of popular Jersey and Tyrus libraries. It explains all mentioned protocols and compares them, in both theory and practice, using java-based examples.
Youtube: https://www.youtube.com/watch?v=G4V3b_z5TVk
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQLAndrew Morgan
Theres a lot of excitement around NoSQL Data Stores with the promise of simple access patterns, flexible schemas, scalability and High Availability. The downside comes in the form of losing ACID transactions, consistency, flexible queries and data integrity checks. What if you could have the best of both worlds? This session shows how MySQL Cluster provides simultaneous SQL and native NoSQL access to your data whether a simple key-value API (Memcached), REST, JavaScript, Java or C++. You will hear how the MySQL Cluster architecture delivers in-memory real-time performance, 99.999% availability, on-line maintenance and linear, horizontal scalability through transparent auto-sharding.
Building scalable, highly-available applications that perform well is not an easy task. These features cannot be simply “bolted” onto an existing application – they have to be architected into it. Unfortunately, the things we need to do to achieve them are often in conflict with each other, and finding the right balance is crucial. In this session we will discuss why scaling web applications is difficult and will look at some of solutions we have come up with in the past to deal with the issues involved. We will then look at how in-memory data grids can make our jobs easier by providing a solid architectural foundation to build our applications on top of. If you are new to in-memory data grids, you are guaranteed to leave the presentation eager to learn more. However, even if you are already using one you will likely walk out with a few ideas on how to improve performance and scalability of your applications.
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015Edward Burns
It’s hard to overstate how much has changed in the world since HTTP 1.1 went final in June of 1999. There were no smartphones, Google had not yet IPO’d, Java Swing was less than a year old… you get the idea. Yet for all that change, HTTP remains at version 1.1.
Change is finally coming. HTTP 2.0 should be complete by 2015, and with that comes the need for a new version of Servlet. It will embrace HTTP 2.0 and expose its key features to Java EE 8 applications. This session gives a peek into the progress of the Servlet spec and shares some ideas about how developers can take advantage of this exciting
update to the world’s most successful application protocol on the world’s most popular programming language.
Hugh Brien of AppDynamics shares his Top 10 application issues he sees on a daily basis.
The list covers:
- Application Performance Monitoring
- Database Monitoring
- Java, .NET, Node.js, PHP, and Python Monitoring
- I/O
- And much more
Node.js and Oracle Database: New Development TechniquesChristopher Jones
These slides are from the AUSOUG webinar viewable at https://www.ausoug.org.au/event/node-js-and-oracle-database-new-development-techniques/
The session covered the best node-oracledb data access features for building great Node.js applications with Oracle Database. Spanning topics from the latest connection pooling advances, right through to efficient ways to access your data, all the best tips are demonstrated. After another busy year of node-oracledb releases, don’t miss the latest on this rapidly growing ecosystem.
This is a technical talk with code snippets demonstrating efficient use of the Node.js node-oracledb driver for Oracle DB. There have been several key releases of node-oracledb over the last year so there is plenty to talk about.
A modern web browser supports a surprising number of protocols designed for fast, efficient, and secure communication. Even though some goals of these protocols might overlap, their features are different enough to make them all worth our attention. This session focuses on HTTP/2, SSE, and WebSocket. It is based on experience gained during development of popular Jersey and Tyrus libraries. It explains all mentioned protocols and compares them, in both theory and practice, using java-based examples.
Youtube: https://www.youtube.com/watch?v=G4V3b_z5TVk
NoSQL and SQL - Why Choose? Enjoy the best of both worlds with MySQLAndrew Morgan
Theres a lot of excitement around NoSQL Data Stores with the promise of simple access patterns, flexible schemas, scalability and High Availability. The downside comes in the form of losing ACID transactions, consistency, flexible queries and data integrity checks. What if you could have the best of both worlds? This session shows how MySQL Cluster provides simultaneous SQL and native NoSQL access to your data whether a simple key-value API (Memcached), REST, JavaScript, Java or C++. You will hear how the MySQL Cluster architecture delivers in-memory real-time performance, 99.999% availability, on-line maintenance and linear, horizontal scalability through transparent auto-sharding.
Building scalable, highly-available applications that perform well is not an easy task. These features cannot be simply “bolted” onto an existing application – they have to be architected into it. Unfortunately, the things we need to do to achieve them are often in conflict with each other, and finding the right balance is crucial. In this session we will discuss why scaling web applications is difficult and will look at some of solutions we have come up with in the past to deal with the issues involved. We will then look at how in-memory data grids can make our jobs easier by providing a solid architectural foundation to build our applications on top of. If you are new to in-memory data grids, you are guaranteed to leave the presentation eager to learn more. However, even if you are already using one you will likely walk out with a few ideas on how to improve performance and scalability of your applications.
HTTP/2 comes to Java. What Servlet 4.0 means to you. DevNexus 2015Edward Burns
It’s hard to overstate how much has changed in the world since HTTP 1.1 went final in June of 1999. There were no smartphones, Google had not yet IPO’d, Java Swing was less than a year old… you get the idea. Yet for all that change, HTTP remains at version 1.1.
Change is finally coming. HTTP 2.0 should be complete by 2015, and with that comes the need for a new version of Servlet. It will embrace HTTP 2.0 and expose its key features to Java EE 8 applications. This session gives a peek into the progress of the Servlet spec and shares some ideas about how developers can take advantage of this exciting
update to the world’s most successful application protocol on the world’s most popular programming language.
Hugh Brien of AppDynamics shares his Top 10 application issues he sees on a daily basis.
The list covers:
- Application Performance Monitoring
- Database Monitoring
- Java, .NET, Node.js, PHP, and Python Monitoring
- I/O
- And much more
Node.js and Oracle Database: New Development TechniquesChristopher Jones
These slides are from the AUSOUG webinar viewable at https://www.ausoug.org.au/event/node-js-and-oracle-database-new-development-techniques/
The session covered the best node-oracledb data access features for building great Node.js applications with Oracle Database. Spanning topics from the latest connection pooling advances, right through to efficient ways to access your data, all the best tips are demonstrated. After another busy year of node-oracledb releases, don’t miss the latest on this rapidly growing ecosystem.
This is a technical talk with code snippets demonstrating efficient use of the Node.js node-oracledb driver for Oracle DB. There have been several key releases of node-oracledb over the last year so there is plenty to talk about.
This is the story of how we managed to scale and improve Tappsi’s RoR RESTful API to handle our ever-growing load - told from different perspectives: infrastructure, data storage tuning, web server tuning, RoR optimization, monitoring and architecture design.
End-to-end Troubleshooting Checklist for Microsoft SQL ServerKevin Kline
Learning how to detect, diagnose and resolve performance problems in SQL Server is tough. Often, years are spent learning how to use the tools and techniques that help you detect when a problem is occurring, diagnose the root-cause of the problem, and then resolve the problem.
In this session, attendees will see demonstrations of the tools and techniques which make difficult troubleshooting scenarios much faster and easier, including:
• XEvents, Profiler/Traces, and PerfMon
• Using Dynamic Management Views (DMVs)
• Advanced Diagnostics Using Wait Stats
• Reading SQL Server execution plan
Every DBA needs to know how to keep their SQL Server in tip-top condition, and you’ll need skills the covered in this session to do it.
Application Performance Troubleshooting 1x1 - Part 2 - Noch mehr Schweine und...rschuppe
Application Performance doesn't come easy. How to find the root cause of performance issues in modern and complex applications? All you have is a complaining user to start with?
In this presentation (mainly in German, but understandable for english speakers) I'd reprised the fundamentals of trouble shooting and have some new examples on how to tackle issues.
Follow up presentation to "Performance Trouble Shooting 101 - Schweine, Schlangen und Papierschnitte"
MongoDB World 2019: Finding the Right MongoDB Atlas Cluster Size: Does This I...MongoDB
How do you determine whether your MongoDB Atlas cluster is over provisioned, whether the new feature in your next application release will crush your cluster, or when to increase cluster size based upon planned usage growth? MongoDB Atlas provides over a hundred metrics enabling visibility into the inner workings of MongoDB performance, but how do apply all this information to make capacity planning decisions? This presentation will enable you to effectively analyze your MongoDB performance to optimize your MongoDB Atlas spend and ensure smooth application operation into the future.
This document describes a set of Progress OE parameters and show how they can impact a Progress OE database performance.
I wrote this document by an easy way so every one can understand it even if he's not a Progress OE DB administrator.
SQL Server Wait Types Everyone Should KnowDean Richards
Many people use wait types for performance tuning, but do not know what some of the most common ones indicate. This presentation will go into details about the top 8 wait types I see at the customers I work with. It will provide wait descriptions as well as solutions.
Real-Time Inverted Search NYC ASLUG Oct 2014Bryan Bende
Building real-time notification systems is often limited to basic filtering and pattern matching against incoming records. Allowing users to query incoming documents using Solr’s full range of capabilities is much more powerful. In our environment we needed a way to allow for tens of thousands of such query subscriptions, meaning we needed to find a way to distribute the query processing in the cloud. By creating in-memory Lucene indices from our Solr configuration, we were able to parallelize our queries across our cluster. To achieve this distribution, we wrapped the processing in a Storm topology to provide a flexible way to scale and manage our infrastructure. This presentation will describe our experiences creating this distributed, real-time inverted search notification framework.
Similar to Database Core performance principles (20)
Explore our comprehensive data analysis project presentation on predicting product ad campaign performance. Learn how data-driven insights can optimize your marketing strategies and enhance campaign effectiveness. Perfect for professionals and students looking to understand the power of data analysis in advertising. for more details visit: https://bostoninstituteofanalytics.org/data-science-and-artificial-intelligence/
Techniques to optimize the pagerank algorithm usually fall in two categories. One is to try reducing the work per iteration, and the other is to try reducing the number of iterations. These goals are often at odds with one another. Skipping computation on vertices which have already converged has the potential to save iteration time. Skipping in-identical vertices, with the same in-links, helps reduce duplicate computations and thus could help reduce iteration time. Road networks often have chains which can be short-circuited before pagerank computation to improve performance. Final ranks of chain nodes can be easily calculated. This could reduce both the iteration time, and the number of iterations. If a graph has no dangling nodes, pagerank of each strongly connected component can be computed in topological order. This could help reduce the iteration time, no. of iterations, and also enable multi-iteration concurrency in pagerank computation. The combination of all of the above methods is the STICD algorithm. [sticd] For dynamic graphs, unchanged components whose ranks are unaffected can be skipped altogether.
As Europe's leading economic powerhouse and the fourth-largest hashtag#economy globally, Germany stands at the forefront of innovation and industrial might. Renowned for its precision engineering and high-tech sectors, Germany's economic structure is heavily supported by a robust service industry, accounting for approximately 68% of its GDP. This economic clout and strategic geopolitical stance position Germany as a focal point in the global cyber threat landscape.
In the face of escalating global tensions, particularly those emanating from geopolitical disputes with nations like hashtag#Russia and hashtag#China, hashtag#Germany has witnessed a significant uptick in targeted cyber operations. Our analysis indicates a marked increase in hashtag#cyberattack sophistication aimed at critical infrastructure and key industrial sectors. These attacks range from ransomware campaigns to hashtag#AdvancedPersistentThreats (hashtag#APTs), threatening national security and business integrity.
🔑 Key findings include:
🔍 Increased frequency and complexity of cyber threats.
🔍 Escalation of state-sponsored and criminally motivated cyber operations.
🔍 Active dark web exchanges of malicious tools and tactics.
Our comprehensive report delves into these challenges, using a blend of open-source and proprietary data collection techniques. By monitoring activity on critical networks and analyzing attack patterns, our team provides a detailed overview of the threats facing German entities.
This report aims to equip stakeholders across public and private sectors with the knowledge to enhance their defensive strategies, reduce exposure to cyber risks, and reinforce Germany's resilience against cyber threats.
Adjusting primitives for graph : SHORT REPORT / NOTESSubhajit Sahu
Graph algorithms, like PageRank Compressed Sparse Row (CSR) is an adjacency-list based graph representation that is
Multiply with different modes (map)
1. Performance of sequential execution based vs OpenMP based vector multiply.
2. Comparing various launch configs for CUDA based vector multiply.
Sum with different storage types (reduce)
1. Performance of vector element sum using float vs bfloat16 as the storage type.
Sum with different modes (reduce)
1. Performance of sequential execution based vs OpenMP based vector element sum.
2. Performance of memcpy vs in-place based CUDA based vector element sum.
3. Comparing various launch configs for CUDA based vector element sum (memcpy).
4. Comparing various launch configs for CUDA based vector element sum (in-place).
Sum with in-place strategies of CUDA mode (reduce)
1. Comparing various launch configs for CUDA based vector element sum (in-place).
Chatty Kathy - UNC Bootcamp Final Project Presentation - Final Version - 5.23...John Andrews
SlideShare Description for "Chatty Kathy - UNC Bootcamp Final Project Presentation"
Title: Chatty Kathy: Enhancing Physical Activity Among Older Adults
Description:
Discover how Chatty Kathy, an innovative project developed at the UNC Bootcamp, aims to tackle the challenge of low physical activity among older adults. Our AI-driven solution uses peer interaction to boost and sustain exercise levels, significantly improving health outcomes. This presentation covers our problem statement, the rationale behind Chatty Kathy, synthetic data and persona creation, model performance metrics, a visual demonstration of the project, and potential future developments. Join us for an insightful Q&A session to explore the potential of this groundbreaking project.
Project Team: Jay Requarth, Jana Avery, John Andrews, Dr. Dick Davis II, Nee Buntoum, Nam Yeongjin & Mat Nicholas
Show drafts
volume_up
Empowering the Data Analytics Ecosystem: A Laser Focus on Value
The data analytics ecosystem thrives when every component functions at its peak, unlocking the true potential of data. Here's a laser focus on key areas for an empowered ecosystem:
1. Democratize Access, Not Data:
Granular Access Controls: Provide users with self-service tools tailored to their specific needs, preventing data overload and misuse.
Data Catalogs: Implement robust data catalogs for easy discovery and understanding of available data sources.
2. Foster Collaboration with Clear Roles:
Data Mesh Architecture: Break down data silos by creating a distributed data ownership model with clear ownership and responsibilities.
Collaborative Workspaces: Utilize interactive platforms where data scientists, analysts, and domain experts can work seamlessly together.
3. Leverage Advanced Analytics Strategically:
AI-powered Automation: Automate repetitive tasks like data cleaning and feature engineering, freeing up data talent for higher-level analysis.
Right-Tool Selection: Strategically choose the most effective advanced analytics techniques (e.g., AI, ML) based on specific business problems.
4. Prioritize Data Quality with Automation:
Automated Data Validation: Implement automated data quality checks to identify and rectify errors at the source, minimizing downstream issues.
Data Lineage Tracking: Track the flow of data throughout the ecosystem, ensuring transparency and facilitating root cause analysis for errors.
5. Cultivate a Data-Driven Mindset:
Metrics-Driven Performance Management: Align KPIs and performance metrics with data-driven insights to ensure actionable decision making.
Data Storytelling Workshops: Equip stakeholders with the skills to translate complex data findings into compelling narratives that drive action.
Benefits of a Precise Ecosystem:
Sharpened Focus: Precise access and clear roles ensure everyone works with the most relevant data, maximizing efficiency.
Actionable Insights: Strategic analytics and automated quality checks lead to more reliable and actionable data insights.
Continuous Improvement: Data-driven performance management fosters a culture of learning and continuous improvement.
Sustainable Growth: Empowered by data, organizations can make informed decisions to drive sustainable growth and innovation.
By focusing on these precise actions, organizations can create an empowered data analytics ecosystem that delivers real value by driving data-driven decisions and maximizing the return on their data investment.
2. Part of Oracle eco-system since 1987
• Have done and seen quite a lot of application development
• Database design, SQL and PL/SQL
Big fan of “Using DatabaseAs a Processing Engine”
• Not just as a layer to persist data
Member of Oracle’s Real-World Performance Group
About Me
3. My Dilemma…
• That what you are about to hear, is probably not going to be of much help to you
• Why?
• Because you are stuck with applications that can’t be changed
• Those applications could run faster *and* use less computing resources, yet would require re-
architecting
• I can only create awareness of this
• My hope is that you can use this talk’s knowledge to influence architectural decisions of future
applications
4. • If I have a single CPU how many processes can be active at any one time?
• And if I have four CPU’s?
• What’s the implication if there are more processes wanting to run than there are CPU’s?
• If my process needs to access an external resource (network, I/O) what happens to it?
• Once request has finished, what decides when my process gets back onto CPU and how much is
it allocated?
• What is the difference between user and sys CPU?
Performance Core Principles: Why?
5. Database Performance Core Principles
• Implications of Oracle’s Process Based Architecture
• End User ResponseTime,Throughput, and DBTime
What happened last two decades with application development?
• It fundamentally moved away from these principles
Agenda
6. Oracle instance = Process based architecture:
Foreground process is serving your database calls
To perform efficiently:
1. process needs to get on CPU as quickly as possible
Process needs to stay on CPU as long as possible:
2. process shouldn’t go to sleep voluntarily a lot
3. process should experience as few involuntary sleeps as possible
Database Performance Core Principles
7. 1: Get On CPU
Oracle
Foreground
Process
Idle CPU
Idle/sleeping
8. 1: Get On CPU
Idle/sleeping
Idle
OS receives interrupt:
figures out which process to
wake-up
Scheduler needs to get this
process on CPU
CPU
Oracle
Foreground
Process
Application issues
database call
All work performed by
OS and scheduler is
reported as SYS cpu
9. • Only one process can be on a core at a time
(it’s either 1 or 0)
• How quickly you can get on core depends
on current utilization
• Higher busy rate higher chance of
spending time on run-queue before getting
scheduled
• Less straightforward with multiple cores
1: Get On CPU
CPU Utilization Chance of getting scheduled
immediately
50% 1 in 2
66% 1 in 3
75% 1 in 4
80% 1 in 5
90% 1 in 10
10. • Not only does it take longer to get on CPU, moreover:
• Busy rate has measurable impact on DB-call response time
• Which becomes noticeable when CPU has 60-65+% busy rate
• This is in essence basic queueing theory, nothing new…
Impact of CPU Utilization on Database Call ResponseTime
11. Database Call ResponseTime, Single Core
R = S / (1 – U) Random arrival
Response time
Service time
Utilization%
R – S = queue-time
while resource is
servicing others
This is an
exponential curve
12. Every system starts queueing at some point, impacting response times
This depends upon:
• Arrival rate, service times, number of cores, and busy rate
More ComplexWith Multiple Cores
Response time
Arrival rate
Service
times
Number of
cores
CPU busy-rate
On busy system,
significant portion of
this is queuing-time
You never want database server to
be running at full capacity all the
time:
stay well clear of 100% busy
13. 2: Stay on CPU, not Go to SleepVoluntarily a Lot
Ten database calls One database call
Completed 10 calls
10Voluntary sleeps
Scheduled 10 times
10 CPUThread
Context Switches
(more SYS cpu)
CPU CPU
Oracle
Foreground
Process
Oracle
Foreground
Process
Insert 10 rows
row-by-row
Array-based or stored proc
14. 6
On 3 GHz core
this is 0.33 ms
This is about 3 µs
This is where Oracle
code spends most of
its time
Fetch by rowid
takes 6-10 µs
15. 2: Stay on CPU, not Go to SleepVoluntarily a Lot
Oracle
Foreground
Process
Oracle
Foreground
Process
Ten database calls One database call
Scheduled 10 times
10 Context Switches
10 Oracle kernel entries
and exits
10 Operating system
entries and exits
CPU CPU
16. Oracle Kernel Entry and Exit
• Like a thread context switch, this too is measurable overhead
If your calls are small and fast
17. Oracle Kernel Entry and Exit
• We measured this in a lab environment
• In summary:
• Simple batch process
• Built in Java
• Single threaded
• Mix of single row selects, single row inserts and single row deletes
• All issued (sequentially) over JDBC to database
• Generating 9000 calls per second
• Using “perf”, we profiled foreground process to see where CPU time is spent
18. Visualizing CPU Usage With Flamegraph
• Perf samples n times per second, the call-stack of your process’ execution thread
• Flamegraph visualizes this
20. How to SpotThis in AWR Report
DB CPU >>
sql execute elapsed time
10,000 seconds of USER cpu
spent on entry/exit
21. How to SpotThis in AWR Report
Do not sum up to 100%, while we
are cpu bound
22. This Overhead Also on Application Servers!
Every process has
this overhead!
23. Full Story Here
• Youtube video: https://www.youtube.com/watch?v=8jiJDflpw4Y
“Koppelaars database”
Status sofar,
• Process architectures have per call overheads:
1. OS interrupt figuring out which process to start (sys)
2. Scheduler doing its work (sys)
3. On-chip microcode execution to re-instantiate process state (sys)
4. Entering Oracle code (user)
24. Oracle instance = Process based architecture:
Foreground process is serving your database calls
To perform efficiently:
1. process needs to get on CPU as quickly as possible
Process needs to stay on CPU as long as possible:
2. process shouldn’t go to sleep voluntarily a lot
3. process should experience as few involuntary sleeps as possible
Database Performance Core Principles
25. 3: Stay on CPU, minimal Number of Involuntary Sleeps
Too many processes
OS scheduler
de-schedules processes while they
still have more CPU work to do =
involuntary context switch
(sleep)CPU
Oracle
Foreground
Process
Oracle
Foreground
Process
Oracle
Foreground
Process
DB call DB callDB call
Three processes all want
to insert 10 rows
(array-based or stored procedure)
Better to have one
process insert 30 rows
27. Database Performance Core Principles
• Implications of Oracle’s Process Based Architecture
• User ResponseTime,Throughput and DBTime
Database Performance Core Principles
28. • Actual duration is measure of performance quality (shorter = better)
• Consistency of response time is an equally important measure of performance quality
• Variance in response times will not delight your users
User ResponseTime
29. 0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
ResponseTime Experienced by User
Frequency X 1,000
Response time sec
Multi-hump indicating response
times with high variance
Long tail
Short tail
Single distinct spike with majority
of user experiences
30. • Throughput is the number of units of work processed within a period of time
• Throughput is not response time
• As the system gets busier, throughput increases (good), but the response time for each individual
unit of work will also increase (bad)
• If you’ve witnessed throughput X at 40% busy,
don’t expect throughput 2*X at 80% busy
Throughput
32. • Response time
• Throughput
• DBTime
Three different things
Remember
33. 0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
ResponseTime Core Principle
Frequency X
1,000,000
Response Time sec
How to
ensure this
Instead of this
Good
Bad
35. Network Network Database
User Experience ResponseTime: Breakdown
Application
End User
Total User Response Time
Time Line
Query
Query
Insert
Delete
Delete
36. Again: %-Busy and Call Counts matter
User Experience ResponseTime:Variance
Breakdown of response time:
Linear relation?
37. How to prevent multi-hump response times
Ensuring Single Spike
Breakdown of response time:
Actual relation!
More calls more queueing
With increasing variance
Smaller = More consistent,
single spike, response times
38. The Oracle database is a process based architecture
To perform efficiently each process requires:
1. to get on CPU asap, and stay on CPU
2. to not go to sleep voluntarily a lot
3. to experience as few involuntary sleeps as possible
Consistent response times require minimization of call counts across components (processes)
DB Performance Core Principles: Summary
You want to stay well clear of
CPU’s being 100% busy
Use architecture that requires small
number of processes
Better to call database
with more work than to
call with little work
43. Despite lots of CPU being used, not much work is getting done
Majority of CPU time is spent on per-call overhead across all layers
With high busy rates on database and application servers
Response times probably aren’t consistent
We Pretty Much KnowThat
45. Conceptually 3 tiers
• Exposed functionality
- GUI's for human interaction
- REST, or otherwise, for software interaction
Internals
• Business logic
• Data store, relational database
High Level Breakdown of OLTP Application
User
Interfaces
Software
Interfaces
Business
Logic
Table
Data Store
46. Two Fundamentally Different Architectures
DBMS = Persistence Layer
"NoPlsql" Approach
DBMS = Processing Engine
"SmartDB" Approach
47. You’ll Always See: Row-by-Row, SingleTable Approach
Single-row data access
Business logic
Row fetching (data access)
Business logic
Row-by-row updating (data access)
“if-then-else-loop” code
PL/SQL here for convenience
Primitive data access
(single table, row-by-row)
48. You’ll Never SeeThis: Set-Based SQL
Decrease the discount percentage on all (still open) order lines,
of a given high-risk order.
Why not?
Because persistence frameworks
aren’t capable of generating this
References >1 table
Affects >1 row
49. “Chatty” Applications When Business Logic Outside DB
“Decrease discount
percentages for high-risk
order”
SQL engine
UI
SQL SQL SQL SQL SQL
High call counts
between processes
SQL SQL
One set-based update,
referencing multiple
tables
SQL engine
UI
SQL or SP-call
50. Two Fundamentally Different Architectures
Aka #SmartDB
All business logic inside database
Only UI outside database
• One user experience = one database call,
reducing voluntary sleeps
• Negligible per-call overhead, as call involves
substantial amount of work
• Requires small number of FG-processes, reducing
involuntary sleeps
Database as Processing Engine
Aka #NoPlsql
All business logic outside database
“Layered Software Architectures”
• Many small calls to database leading to high
rate of voluntary sleeps
• Noticeable per-call overhead, as call is single
row statement
• Requires large number of FG-processes risking
high rate of involuntary sleeps
Database as Bit Bucket
Youtube: “asktom
connection pool”
51. Every SQL statement submitted from application server
• Requires OS entry
• Requires OS scheduling
• Requires CPU context switch
• Requires Oracle kernel entry
Before it arrives at SQL-engine
Sum of these fixed CPU overheads is very real
for row-by-row SQL!
• Could be 2X CPU knock-on to SQL execution
Implication ForYour Computing Resources Footprint
52. Network Network Database
Implication ForYour Footprint: Affects Application Server too
Application
End User
Not just on database server: on application server as well
Query
Query
Insert
Delete
Delete
:Thread context switch
53. Micro Services Architecture: Rife With Context Switches
End User
Check BalanceAudit Event
Time Line: breakdown consists of many more components
v v
More components risk
of more variability
54. Introduce ridiculous inefficient use of availableCPU resources
Only way to improve this move away from row-by-row processing
This requires hand-written set-based SQL
Implication of Moving Business Logic Out of DBMS
We see database cores spending up to 60% of CPU-cycles
on OS and CPU context-switches and getting in/out database kernel
And application servers spending majority of time descending
and ascending up JDBC and framework layers
55. Want to Get an Idea of Inefficiency onYour Server?
High Sys-to-User ratio is
good indicator
You’re not using DBMS as it
was designed to be used
56. How to ReduceYour Computing Resources Footprint?
DBMS = Persistence Layer
More busy
DBMS = Processing Engine
Less busy
57. The #SmartDB gains of:
• Massive reduction in call counts, greatly diminishes all aforementioned
overheads per call
• Outweigh additional work you bring into database by implementing
your business logic inside SQL and PL/SQL
Here IsThe, Counter Intuitive, Core Fact
58. • Majority of current applications have large computing resources footprints
• Why? Because they were built using layered software architectures and have all business logic
execute on application servers
• These architectures cause very high call counts across components (processes), and thereby they
violate all database core performance principles
In Summary
59. • If you want to reduce your computing resources footprint
Don’t bring data to code, bring code to data, use smart SQL
• Focus on minimizing chattiness, process context switches, call-counts, etc.
• You’ll reduce both your database-server footprint, as well as your application-server footprints
• And your user experiences will be consistent
• Questions: emailToon.Koppelaars@oracle.com, twitter: @toonkoppelaars
In Summary