2018 jk
Upcoming SlideShare
Loading in...5
×
 

2018 jk

on

  • 268 views

 

Statistics

Views

Total Views
268
Slideshare-icon Views on SlideShare
268
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 3 tier Application topologies are common today. Traditionally, to scale you have to scale at all tiers, which means proliferation of web server and application server tiers and the complexity or manual work that can be required to manage & maintain them. You also have a database that you continue to scale up, but eventually becomes a bottleneck for your transaction processing, and you reach the physical and cost limitations quickly. Servers multiply quickly following this approach… There is a simpler way to address the scaling needs for your applications. Enter elastic data grids based on XC10 and WXS… Sure, you will grow your web tier and your app server tier some. But by adding an elastic data grid into your architecture, you can very quickly and easily scale out your transaction volumes with minimally invasive changes to your app and architecture. By doing this, you also drastically reduce your reads & writes on the database, cutting back on those time and resource intensive calls that created your bottleneck. We’ll talk a bit more about the details of how this works in a second. Elastic data grids are enabled by WXS running on commodity hardware (x86 boxes) or the new XC10 Appliance. Both solutions are easy to access and cost effective to “add a few more” as you continue to grow. XC10 provides 160GB cache in one box, pre-bundled to save customers time when adopting a distributed caching solution for common scenarios such as WAS HTTP Session Replication and extension of the Dynamic Cache Service.
  • 300 active users across 2 Portal servers 2 XC10s used for XC10 cache scenario Performing Wiki/Blog browsing simulation
  • 300 active users across 2 Portal servers 2 XC10s used for XC10 cache scenario Performing Wiki/Blog browsing simulation
  • Measure performance of a newly started server With Default Advanced Cache this means an empty cache With XC10 Offloaded cache, the shared cache is still warm Measure performance during first 30 minutes of load after server start
  • XC10_Overview.ppt Page of 14 IBM WebSphere DataPower XC10 supports session data cache for WebSphere Application Server. Session management data caching exists in current releases and previous releases of WebSphere Application Server. DataPower XC10 provides extensions so that WebSphere Application Server can now use the appliance for the session data cache, instead of relying on local JVM memory or data base storage. You can create the session data caches ahead of time in the appliance, and then using the WebSphere Application Server administrative console, you can associate servers directly with the data cache that you’ve already created. Alternatively, you can use the WebSphere Application Server administrative console to create the session data cache on the appliance at the time you enable the server for session data caching.

2018 jk 2018 jk Presentation Transcript

  • 2018 Designing a Scalable and High Performing Portal Infrastructure Hide Details James Krueger – WXS Development Nitin Gaur – Application Infrastructure and Mobility With Thanks to Benjamin Parees – WXS Development Paul Chen – WXS Development© 2013 IBM Corporation
  • Please note: IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.2 © 2013 IBM Corporation
  • Primary Market Drivers• The competition is only a click away in todays web-facing world.• Response times are critical to giving customers a good experience and generating revenue.• Customer sessions are becoming more critical.• The cost of attracting new customers to your web site for enrollment is significant.• Losing the data that they have entered will likely create a negative impression and result much higher abandonment rates
  • AgendaMotivationPortal Topologies – Conventional and FarmOverview of DynaCache and the Portal Advanced CacheReview Performance ResultsConfiguration OvervieweXtreme Scale and XC10 Background4 © 2013 IBM Corporation
  • Portal Topology : Conventional or Farm? Conventional Topology Portal Farm Topology © 2013 IBM Corporation
  • What is a Portal Farm?■ A series of identically configured, stand-alone portal instances■ No managed cell, no clustering, no Deployment Manager – Just Stand-Alone Application Servers runtimes!■ Workload management handled using any load balancer – HTTP Server plug-in can be used with manual configuration■ Server instances treated as commodities – Rip-n-replace – Can more easily mix/match maintenance levels■ Extremely simple to grow/shrink capacity based on demand■ Particularly well suited for cloud-based deployments WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP WP6
  • Typical Customers who is using Portal Farms• Banks• HR services providers• Companies that need continuous availability• Companies that are using LPARs or virtual images and SANs to run their Portal and want to simplify maintenance.• Companies that do not wish to set up and maintain multiple Portal clusters.  WAS Extended Deployment• Keep it simple and make it work. 7
  • Portal Farming – What is Missing?• Ultimate simplicity at the loss of some functionality  DB or grid-based session persistence and failover only*  No distributed cache management*  No distributed EJB usage  No synchronized configuration (without the aid of file system utilities)  No coordinated task scheduling  No cluster-scoped administrative actions − Start/stop applications − Can be replaced by “flexible administration” or scripting• Customers need to understand these limitations before considering a farm-based deployment 8
  • Why Choose Farming?•Farming is a simple architecture with just a seriesof identical stand-alone portal instances with load Unique install Portal Farmbalanced by a HTTP plug-in or any load balancer Requests•Server farms are effective way to build and maintain LBa highly scalable, highly available serverenvironment•Farms allows Dynamic Server Expansion and Node Node Nodecontraction of size without complex cluster Portal1 Portal Portal1configurations which are usually time consuming•Sourcing additional servers using cloning or REL JCR REL JCR REL JCRvirtualization is very rapid. With WP7 Sharedconfiguration it is much more rapid and simple•Client had a very tight maintenance window. CUS COMDeployments on clusters, Synchronizing clusters isstretching maintenance window•Though administrative actions need to berepeated on each server independently, this can beachieved automation scripts or tools• Customer understood the limitations of Farming –like Distributed caching, EJB, cluster administrationetc.
  • Multi-Tenant Design Features • Hosting Multiple clients on shared infrastructure • All the customers are hosted on a huge infrastructure cloud • Dynamic launching of clients enabled • Clients are allowed to choose services from list of available services • Provide complete client isolation so each client operate in its own SILO •Resource sharing is enabled at various levels but not transparent to clients – Shared resources are • Hardware • Server and JVM resource – CPU, Memory, Disk Space • Portal instances • Client identity (Branding) is handled by providing custom personalization at application design10
  • Client isolation and insulation – Conceptual model • Every customer needs to be in his own virtual environment and completely isolated • Insulated from information spill and Load fluctuations • Is physical isolation a reasonable solution? A Client A Client A Client A Client A Client A Client SILO SILO SILO SILO SILO SILO Gateway Gateway Gateway Gateway Gateway Gateway Security Security Security Security Security Security Web Tier Web Tier Web Tier Web Tier Web Tier Web Tier Portal Portal Portal Portal Portal 57K Clients Portal App Tier App Tier App Tier App Tier App Tier App Tier DB Tier DB Tier DB Tier DB Tier DB Tier DB Tier11
  • Need for a Common Tier : Conventional OR Farm Topology •Need for a common tier •Keep State Information •Tier for HTTP session caching • Efficient WCM cache •Other common redundant cache •Off-load Dyncache •Lighter Portal JVMs •Reduce CPU utilization due to GC •Efficient CPU Utilization – reduced complex cache activity. •Efficient middleware Growth© 2013 IBM Corporation
  • Elastic Caching minimizes the impact ofTransaction OverloadWeb Server Tier App Server Tier Elastic Cache Back-end Systems Database Tier Improve Performance, Scalability & Availability Highly Scalable Web Applications Data-intensive Applications Extreme Performance WebSphere IBM HTTP Server DB2 UDB Application Server
  • Innovative Elastic Caching Solutions “Data Oriented” Session management Elastic DynaCacheDataPower XC10 Appliance Web side cache• Drop-in cache solution Worldwide cache optimized and hardened for data oriented scenarios Data buffer• High density, low footprint eXtreme Scale improves datacenter Event Processing efficiency Petabyte analytics • Ultimate flexibility across a broad range of caching In-memory OLTP scenarios • In-memory capabilities for In-memory SOA application oriented “Application Oriented” scenarios Elastic caching for linear scalability High availability data replication Simplified management, monitoring and administration 14
  • Session Caching for WebSphere Portal
  • Applications using DynaCache Each JVM has a private disk based cache to support caches much larger than possible with a memory only conventional cache 2 tier cache: JVM has a small local cache, then the disk file. Cached content is redundant across JVMs16
  • News Portlet Deployment - Failure !#*! DynaCache W e lc o m e , WPS disk-offload U ser! DynaCache WPS disk-offload … too slow! DynaCacheDuring a recent ‘News’ application promotion, the WPS disk-offloadcustomer response to the new portlet overwhelmedthe web-site. The web-site became painfully slowunder the significant load. The result, not a happycustomer… DynaCache WPS disk-offload
  • Scalability: Off-loading Dynamic cache to WXS/XC10Much larger cache capacity WebSphere Portal JVMs runmore efficiently – Lower local memory requirements – Faster start-up timeImproved consistency ofperformance – Improved cache and environment stability – High availability of cached data18
  • News Portlet Deployment - Success Elastic cache W e lc o m e , U ser! WPS W XS WPSDuring a recent ‘News’ application promotion, the WPScustomer response to the new portlet was very high. With WXS DynaCache GridHowever, with addition of an elastic cache the web-site configured, disk-offload is nowas able to handle the significant increase in load. The longer requiredcustomers did not perceive any slow down of the web-site. The result, happy customers and a successfulcontent promotion… WPS
  • Fast start-up when adding more capacity – on the fly Elastic cache WPS W e lc o m e , U ser! WPS W XS WPSNew WebSphere Portal servers can bebrought on-line quickly to meet increased WPScapacity needs. When start-up iscomplete, the new server has immediateaccess to a warm cache provided byeXtreme Scale. WPS New Server
  • Maintain consistent user experience during site maintenance Elastic cache WPS W e lc o m e , U ser! WPS W XS WPSIf a WebSphere Portal server needs to berestarted after applying an iFix, eXtreme WPSScale can provide up to 54%improvement in time to reach steady-state WPS Down for maintenance
  • Scenario Details Two Portal Servers with Web Content Manager  300 concurrent users simulating Wiki/Blog accesses Single WCM DB Server  Web Content Manager DB content: 50 gigs Two XC10 Caching Appliances Advanced Cache maximum entries Using App Server heap: 5000 per server Offloading to XC10: 1,000,000 shared available (Observed ~9 gigs) WPS+ WCM 2 XC10 Collective Proxy WPS+ WCM WCM DB
  • Portal Customer Experience – Steady State ComparisonEnabling WebSphere Content Manager Cache Offload Performance Advanced Cache using an offloaded eXtreme Scale/XC10 grid cacheWith WXS/XC10 average throughput in our 100 steady state/concurrent user scenario was 90 consistently faster than with Default No WCM Advanced 80 Cache Advanced Cache WCM Advanced 42% improvement over no Advanced 70 Cache Offloaded to Cache in our scenario 60 XC10 50 24% throughput improvement over Throughput(requests/second) default cache implementation using Application Server JVM heap in our scenario 100Using the Default Advanced Cache implementation requires available 90 Default WCM Application Server heap, offloading the 80 Advanced Cache cache to WXS/XC10 does not require 70 WCM Advanced Cache Offloaded to heap 60 XC10 50 Throughput(requests/second)Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. Actual performance in a users environment may vary.
  • Portal Customer Experience – Steady State ComparisonWith WXS/XC10 average steady state Cache Offload Performance response-times are consistently faster than with Default WebSphere Content Manager 16 Advanced Cache 14 5.5 second improvement over no 12 No WCM Advanced Cache Advanced Cache in our scenario 10 WCM Advanced 8 Cache Offloaded to 3.4 second improvement over default XC10 6 cache implementation using 4 Application Server JVM heap in our Response Time(seconds) scenario 16Performance is based on measurements and 14 projections using standard IBM 12 Default WCM benchmarks in a controlled environment. Advanced Cache 10 Actual performance in a users WCM Advanced 8 Cache Offloaded environment may vary. to XC10 6 4 Response Time(seconds)
  • Reducing Portal warm-up time – Cold Start ResultsWith WXS/XC10 average throughput of a Cache Offload Performance newly started server is consistently faster than with Default WebSphere Content Manager Advanced Cache 90 54% throughput improvement in 80 Default our scenario 70 Advanced Cache 60 Advanced 50 CacheWith WXS/XC10 average response-times 40 Offloaded to are consistently faster than with XC10 30 Default Advanced Cache Throughput(requests/second) 4 second improvement observed in our scenario 16With WXS/XC10 response times 14 improve faster due to quicker cache 12 Default Advanced Cache hydration 10 Advanced Cache 8 Offloaded to XC10 6Performance is based on measurements and projections using standard IBM 4 Response Time(seconds) benchmarks in a controlled environment. Actual performance in a users environment may vary.
  • Summary of Primary BenefitsWCM Advanced Cache implemented through the DynaCache, stores fully rendered pages that do not have to be pulled out of WCM DB. Today customers can enable Advanced Cache in the app server’s heap space. Technical goal is to avoid trips back to the WCM database to avoid building these pages. WXS plugin allows you to store the DynaCache content in a remote grid, so that the data being inserted into DynaCache does not consume app server heap space. 1. Caching is of highest importance with WCM. Complex WCM components can be very CPU intensive 2. WXS grid can store more data, have a larger hit percentage than DynaCache and reduce trips to WCM DB which is more expensive. (More consistent Response times) 3. Benefits customers who are heaped constrained (no DynaCache) can leverage the Advanced Cache by not committing memory on their Portal server. The WXS scenario does not consume memory on the Portal server. 4. Shared cache, each portal JVM does not have to warm its cache on server restarts 5. Eliminates invalidation chatter.. critical in the farm topology
  • Legal disclaimer © IBM Corporation 2013. All Rights Reserved. The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete: Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the users job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete: All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation.Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation. If you reference Adobe® in the text, please mark the first use and include the following; otherwise delete: Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. If you reference Java™ in the text, please mark the first use and include the following; otherwise delete: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. If you reference Microsoft® and/or Windows® in the text, please mark the first use and include the following, as applicable; otherwise delete: Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. If you reference Intel® and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete: Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. If you reference UNIX® in the text, please mark the first use and include the following; otherwise delete: UNIX is a registered trademark of The Open Group in the United States and other countries. If you reference Linux® in your presentation, please mark the first use and include the following; otherwise delete: Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta Bank, Acme) please update and insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration purposes only. 27 © 2013 IBM Corporation
  • Back-Up Slides© 2013 IBM Corporation
  • Related Key Features in Recent WXS Release (8.6)• eXtremeIO (XIO) • Replaces Object Request Broker (ORB) • More efficient transport layer• eXtreme Data Format (XDF) • Serializes data for sharing between Java and C#/.NET applications. • Index data on server without requiring user classes to be present. • Automatic Versioning of classes• Portal Farm Impacts • Further performance improvements possible with XIO. • The elimination of data serialization requirements will broaden Portal caches that are appropriate for offload to WXS.29
  • Cache Instance Configuration
  • DynaCache Instance Configuration
  • Portal Advanced CacheDynaCache instance used to store rendered contentSpecifically content pulled from a Web Content Manager databaseConfiguration used Site level caching (rendered content) 30 day expiration Do not clear cache on startup
  • So, what are eXtreme Scale and XC10 anyway?33
  • IBM WebSphere eXtreme Scale• Proven mature product: – Fourth major release of product with V7.1 – Public References – Private References – Used at some of the largest web sites/companies in the world• Lightweight runtime footprint (20MB jar)• Integrates with all versions of WebSphere and almost any Java-based application container or Java Virtual Machine• Proven multi-data center capabilities• Proven low-latency access to data
  • IBM WebSphere DataPower XC10 V2 New Form Factor (2U) Larger Cache (240 GB) Better Performance (Faster SSD, Use of RAM) Improved monitoring (SNMP Support) Support for non-Java Applications (REST Gateway) Grid Capping
  • Utilizing WebSphere DataPower XC10 for DynaCache Clients can attach to the ‘cache’ using the network No dependency on a large file system cache. No disk dependency, no SAN required. Network Cache is as large as the XC10 Collective memory in the ‘grid’. Each record is stored once in the grid and shared by all clients.36
  • HTTP Session data cache  No new code required  Extension of legacy session management caching mechanism in WebSphere Application Server  Extensions to WebSphere Application Server administrative console to support WebSphere DataPower XC10 session management caching and WebSphere eXtreme Scale session management caching  WebSphere Application Server connects seamlessly to the WebSphere DataPower XC10 appliance or WebSphere eXtreme Scale – Client code must be installed on WebSphere Application Server systems  Easily configure WebSphere applications to store HTTP session data to a data cache on the WebSphere DataPower XC10 appliance through the WebSphere Application Sever administrative console  Replaces other session replication mechanisms (memory-to-memory replication)  Removes the need for Database traditionally used for persistence  Enables HTTP session failover between WebSphere Application Server cells37
  • Farming: Shared installations & Session caching •Ability to share the profile & persist session Manage the life cycles of HTTP sessions that are associated with the application Improve QoS and Lower Memory footprint Better guarantees of session availability during server failover Topology spans multiple data centers across different physical locations Elastic Cache DataPower XC10