1 / 27

Best Practices for Optimizing Blackboard Learn

Best Practices for Optimizing Blackboard Learn. Steve Feldman, sfeldman@blackboard.com. What We’ll Cover. A deployment approach for the ages. How to make use of the new sizing guide. Optimizing the platform components. Flexible and Scalable Application Deployment.

dagmar
Download Presentation

Best Practices for Optimizing Blackboard Learn

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Best Practices for Optimizing Blackboard Learn Steve Feldman, sfeldman@blackboard.com

  2. What We’ll Cover • A deployment approach for the ages. • How to make use of the new sizing guide. • Optimizing the platform components.

  3. Flexible and Scalable Application Deployment

  4. Flexible and Scalable Application Deployment • An ideal deployment will contain… • Availability at every edge of the application environment • Strategy: Physical distribution of load-balanced systems • Strategy: Minimum DB recovery, not necessarily 0 downtime • Consumption of every possible machine resource • Strategy: Virtualization provisioning • Techniques for improving user experience • Strategy: Techniques and tools for achieving page-level SLAs • Large addressable memory spaces • Strategy: 64-bit and large OS process space allocations

  5. Flexible and Scalable Application Deployment • An ideal deployment will contain… • Minimum Storage Recovery Time • Strategy: Enterprise storage with Snapshot capabilities • Advanced monitoring for operations and planning • Strategy: Measurement tools and analytics • Automation…Automation…Automation • Strategy: Investment in repeatable, reliable automated processes.

  6. Deployment: Availability • VLEs are different beasts today then in the past. • Communities are bigger • Sessions last longer • Content is richer • Key point: Adoption is greater and users expect their sites up 24 x 7 x 365 • Architecture is designed for many parallel instances of the product scaled in a horizontal fashion. • Distributed physical deployments • Virtualization is a key element • Database failover more important than horizontal database scalability. • Emphasis on vertical database scalability

  7. Deployment: Resource Utilization • Moore’s law is in full effect • CPUs are getting faster with more cores • Memory is in abundance and cheap • Storage is grossly abundant • Massive systems can be obtained at low cost, but cannot be saturated in stand-alone configurations. • Virtualization offers the opportunity… • Deploy with availability in mind • Saturate system resources

  8. Deployment: Improving Page Responsiveness • Gzip…Gzip…Gzip… • All of our supported browsers handle gzip? • Reduces payload • Improves lower latency connections like Cable, DSL and Dial-up • Minor overhead on the application layer (~2% to ~5%) • Have the option to perform at the load-balancer layer • Most Bb deployments do not enable Gzip at all • Even when enabled, some proxies and software packages mess-up the Accept Encoding Header • Optimize your images • Page size really does matter • Reduce the size without reducing the quality

  9. Deployment: Large Address Space • As of Blackboard Learn™ Release 9.1 all supported/certified configurations include a 64-bit option. • Pushing more processing to client and DB over the last few releases, but major memory management technique is to use more application caches. • Memory stays persistent longer • Less wasteful from a creation/destruction perspective, but puts greater demands on larger spaces. • Most of our application testing focused on 4GB and 8GB JVM deployments on 6GB and 10GB OS spaces. • Limited testing at 16GB and 32GB

  10. Deployment: Storage MTTR • Reference architecture pushes for “diskless” boots in which ISCSI or NFS partition resides on an enterprise storage system. • Both OS/VM partition and data partition served up from remote storage deployment designed for performance and scalability. • Make your hardware work from a CPU, Memory and Network perspective…save the Disk for the experts. • Consider scenarios for reducing “Mean Time to Recovery or Repair” • Snapshot technology offering minutes for recovery

  11. Deployment: Advanced Monitoring • Measurement is the secret sauce for successful deployments. • Most reliable and scalable deployments measure beyond the server infrastructure • Different types of measurements • System/Environmental measurements • Business measurements • Synthetic measurements • Collecting is only part of the prize • Need to analyze the data to drive business decisions from the data.

  12. Deployment: Automation • Goal of moving to 100% unattended and fully automated deployment. • Reduce MTTR and prevent disasters • Automation requires intimacy…intimacy requires knowledge • Use automation for • Configuration Management and Deployment • Maintenance • Repeatable tasks • Adaptive tuning • Minimize possibility of human error • http://dev2ops.org/storage/downloads/FullyAutomatedProvisioning_Whitepaper.pdf

  13. Sizing the Application: To Hyper-Thread or Not • Applies to Intel deployments only • “..delivers thread-level parallelism on each processor resulting in more efficient use of processor resources—higher processing throughput—and improved performance on multi-threaded software.” –Intel Corporation • Greatly improved in series 5500+ processor • Provides double worker thread capacity • If it’s not turned on, stop what you are doing and enable it ASAP!

  14. Moving Away from Clusters • Tomcat clusters were introduced back in Blackboard Learn 7.X prior to the transcendence of server virtualization. • Only supported 32-bit configurations at the time, but systems were being shipped with 8GB, 16GB and 32+GB of RAM. • Needed a way to take advantage of memory, but were limited to a 1.7GB address space. • Recommending “distributed” deployment approaches as well. • Still applies, but can be achieved differently. • Clustering has its advantages, but also has its penalties. • Failover not as ideal as one would desire. • Best approach is to scale up with 64-bit spaces and distributed JVMs across both virtual and physical configs

  15. Sizing Using P.A.Rs • PAR = Performance Archetype Ratios • Methodology for sizing based on units of work that can be applied to “unit of configuration” • PARs assume a world of linear units • Add units of configuration to meet growing demands of unit of work. • PARs based on (4) key resources: CPU, Memory, Disk and I/O and application interfaces (threads and connections). • Used for making capacity decisions for sizing both virtual and physical components.

  16. Optimizing the Web Server • The web server in the Blackboard Learn configuration is nothing more than a gateway to the application container. • When clusters were more relevent, the web server acted as a pseudo load-balancer. • Not many opportunities for optimization other than • KeepAlives • Interfaces • Compression • It can become a bottleneck if not properly optimized • Better to have high ceilings from an interface perspective

  17. Optimizing the JVM • Java hotspot offers standard –X and non-standard –XX options for performance and behavior. • -X options are always guaranteed across releases and patches of Java. • -XX options must be used with caution as they are subject to change with any release of Java. • -XX options should be tested and measured using the production safe arguments. • Read the release notes of Java for “performance” updates • http://java.sun.com/javase/6/webnotes/ReleaseNotes.html

  18. Optimizing the JVM • Cross-platform recommendation for using Concurrent Mark Sweep Collector • Best optimized for 64-bit address • Combine –XX:+UseConcMarkSweepGCwith –XX:+UseParNewGC • Manually size New Space using –XX:NewSize and –XX:MaxNewSize options (1/4 to 1/3 total heap). • Consider Survivor Space ratios 4 or lower. • Be careful about sharing –XX non-standard options across customers. • If you don’t understand what the option does and it’s not recommended by Blackboard, best choice is to not use it.

  19. Optimizing the Database: SQL Server • # of data files makes no difference on SQL Server for Data and Transaction • Allow the data/transaction files to grow as big as they want within reason. • What’s reason: 64GB • http://msdn.microsoft.com/en-us/library/ms143432(sql.90).aspx • TempDB is completely different story • # of files = # of DB Threads • Set first X files to a uniform size, set last file to same size with auto-extension ON • Determine size need over time • Separate volume for paging file

  20. Optimizing the Database: SQL Server • Be aware of MDOP: Max Degree of Parallelism • Setting to unlimited can have a negative affect on query performance unintentionally. • AWE can and does work on 64-bit systems • Configure READ_COMMITTED_SNAPSHOT • Two nuggets of information: • Learn How to Use SQL DMVs • Study SQL Server Wait Events and Tuning

  21. Optimizing the Database: Oracle • Balance I/Os across multiple data files (~2 to 8GB per file). • REDO is critical to performance a session/query level. • Be aware of how much REDO is being used over time. • NOLOGGING will disable, be we rarely use NOLOGGING • TEMP is very complex and used for managing transient data. • One TEMP file is adequate • If latency exists on TEMP, consider introducing TEMP file groups • SGA is important, but PGA can be your best friend or your worst enemy with high concurrency.

  22. Optimizing the Database: Oracle • Oracle DBO can be your friend • Must understand optimizer behavior • Willingness to read Cost Execution Plans • Using Wait Events and Cost Execution Plans for tuning initiatives • Wait events are at a system, session and query level • Importance of Statistics and Histograms • CBO is just guessing without properly set statistics and histograms. • CBO is dependent on your data.

  23. Please provide feedback for this session by emailingBbWorldFeedback@blackboard.com. The subject of the email should be title of this session: [INSERT TITLE HERE]

More Related