JahiaOne - Performance Tuning

3,201 views
3,176 views

Published on

Building highly scalable website requires to understand the core building blocks of your applicative environment. In this talk we dive into Jahia core components to understand how they interact and how by (1) respecting a few architectural practices and (2) fine tuning Jahia components and the JVM, you will be able to build a highly scalable service

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,201
On SlideShare
0
From Embeds
0
Number of Embeds
1,992
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

JahiaOne - Performance Tuning

  1. 1. Jahia Performance Tuning Hayssam Saleh - ebiznext
  2. 2. Summary  Ecommerce is what we do  How we came to Jahia ?  The performance bottlenecks  How me made our servers busy sleeping  How Jahia treat its users equally (well)  A (Jack)Rabbit can’t be slow unless you want it to.  Assumptions  Publication nodes are for publishing only  My promise  Won’t talk about anything already in the docs.
  3. 3. Ecommerce is what we do The easy part Metropolitan Transportation Pass The challenge 200.000 Pass / hour 55 Pass / second 250 hits/ second Selfcare services The challenge 30.000 users / minute The hard part Now do it with a CMS
  4. 4. Performance bottlenecks Browser Jahia1 Browser Browser Data Browser Jahia2 Browser Network bottleneck Always on Scalability Slow access
  5. 5. How me made our servers busy sleeping
  6. 6. How we made our server busy sleeping Browser Browser Jahia1 Browser Browser Browser Data Jahia2
  7. 7. Jahia Caching (1/3) Jahia1 EHCACHE Data Jahia2 EHCACHE  DiskStore Policy which is 20 times slower than Memory Store  Writing is slow  Writing to disk uses OubjectOutputStream which is 18 times slower than byte copy  Eviction is costly  Not only does EhCache write data to disk it also need to remove it from the memory store  Reads from disks require deserialization + disk reads and they are both synchronous
  8. 8. Jahia Caching (2/3)  DiskStore Policy which is 20 times slower than Memory Store  Writing is slow  Writing to disk uses OubjectOutputStream which is 18 times slower than byte copy  Eviction is costly  Not only does EhCache write data to disk it also need to remove it from the memory store  Reads from disks require deserialization + disk reads and they are both synchronous  If you have to use the DiskStore policy then :  Use SSD drives  Deastivate disk schedulers (set elevator to noop)  Limit disk access by setting noatime
  9. 9. Jahia Caching (3/3)  MemoryStore Policy      Memory is faster than disk  Byte Copy is faster than Object serialization  Require to increase JVM Memory and the GC does not like it  Memory is subject to GC  EhCache (commercial version) can use Off Heap Memory   Not subject to GC   Allocated outside the JVM   Managed by EhCache externally  No perfect solution ?  The truth is elsewhere 
  10. 10. Reactive Caching Cloud effective Cache invalidation Browser Jahia1 Browser Browser Browser EhCache DiskStore Akamai / CDN / Varnish Data Jahia2 EhCache DiskStore Browser Cache invalidation <cacheEventListenerFactory class="fr.mycompany.jahia.services.ehcache.AkamaiListenerFactory" properties="akamaiUrlprefix=www.mycompany.fr, type=arl, domain=staging, action=remove" listenFor="all" /> + 100 lines of Java code
  11. 11.  Jahia treat its users equally (well)
  12. 12. The problem we wanted to solve What we wanted Hot deployment Zero downtime Continuous deployment No human intervention What we got What we wanted Almost linear scalability
  13. 13. Green / Blue deployment Zzzzz Green Line Blue Line App1 App1 App2 App2 App3 App3 Install Blue Line Open Blue Gates Close Green Gates Wait for sessions to die Install Green Line  An what if we did not have any session ???
  14. 14. What we did ? Jahia stateless Browser L o a d B a l a n c e r Session Jahia1 Session Session Session Browser Jahia2 Session Round robin does not guaranty Equal session lifetime 80 lines of Java code inside a Jahia Filter L o a d B a l a n c e r Session Jahia1 Session Session in cookie based Jahia stays Stateless Jahia2
  15. 15. Canari Deployment Canari App1 App1 App2 App2 App3 App3 Foreach Stop Install Start
  16. 16.  JackRabbit Best Practices My name is not Jack
  17. 17. JackRabbit versus SGBDR versus File System Content Repository SGBDR Integrity File System Hierarchy Structure CRUD Queries Transactions Notifications Versioning ACL Full Text Search
  18. 18. Performance tuning  Indexing is done asynchronously  Data is available after a short delay  Disabling it  If you don’t use it comment out SearchIndex in workspace.xml  Avoid extra useless searches  For each node returned by Lucene, JackRabbit checks the ACE for that node  Set the property resultFetchSize accordingly  Defaults to 100  Adjust Lucene to JackRabbit Ids correctly  Set the property cacheSize to maximize cache hits  Available in RepositoryStatitics
  19. 19. Performance tuning  Avoid multiple I/O on your DB  Set minRecordLength to a value that avoid read/write to be larger than DB Unit of I/O  Unit of I/O defaults to 8K for Postgres, Oracle, SQLServer  Avoid too many references to a single node  JackRabbit is node oriented  When links between nodes matters we use a Graph database  Tuple Visit(Page, User)  Tuple Like(Page, User)  For large node sets  Add extra levels  Paths quickly reduce the search domain  Speedup write  Use usual transaction patterns  Write asynchronously whenever possible
  20. 20. Questions My name is Jack

×