3 Deployment Checklist Liferay Portal 6.1 Enterprise Edition Introduction The Liferay Engineering team has performed intensive performance and scalability testing on Liferay Portal Enterprise Edition (LPEE) and the accumulated knowledge has been condensed into this checklist. Although a portal s performance profile may differ depending on several factors, this checklist will provide a list of critical parameters to monitor for tuning and some initial settings to use as a starting point. These initial settings have withstood heavy testing by the Liferay Engineering scalability team. Reference Architecture The selection of an appropriate architecture is one of the first decisions in your deployment path. To select an appropriate architecture, you must consider: Security securing sensitive hardware and information from malicious attack and intrusion Performance - number of total users, concurrent transactions, etc Fault Tolerance allowable downtime due to failure or maintenance Flexibility and Scalability expand architecture to support additional features and users without significant redesign Although appearing somewhat complex, the reference architecture depicted in Figure 1 provides high levels of fault tolerance and flexibility. 1

5 Virtualized and Cloud Deployments While the reference architecture describes a physical deployment, the same concepts may be applied towards a cloud based or virtualized deployment. Many Liferay customers choose to deploy on either public clouds (e.g. Amazon EC2) or their own private clouds (e.g. VMWare VSX based private cloud). Each physical machine may be replaced by appropriate quantities of virtual machines. In the virtualized deployments, it is critical to allocate sufficient CPU resources. For instance, for systems deployed to Amazon AWS, allocated CPUs are calculated using Amazon EC2 Compute Units. However, 1 Compute Unit does not equal to 1 CPU or even 1 core on a CPU. In Amazon s terms, each application server used in the reference architecture equates to a Cluster Compute Quadruple Extra Large Instance, or roughly 33.5 EC2 Compute Units. Thus, to properly plan the virtualized/cloud deployment, customers must account for not only virtualization overhead, but also ensure allocation of sufficient resources. Security The firewall preceding the Load Balancer Tier will provide sufficient intrusion detection and prevention. However, depending on your organization s info-security requirements, you may introduce additional firewall layers between each tier to further secure the infrastructure. Performance Each portal deployment s performance characteristics will vary depending on the type of activity and any custom application elements. Liferay Engineering has created a series of scenarios to benchmark LPEE s out of the box performance characteristics for content management, collaboration, and social enterprise. The final results of these scenarios will be shortly published to all LPEE customers. However, initial results from the reference architecture have indicated LPEE can support over 18,000 virtual collaboration users and over 150,000 logins per minute with an average login time of 300 milliseconds. LPEE accomplished this load within the reference architecture while utilizing no more than 40% of CPU resources in the Web Tier, 88% of CPU resources in the Application Tier, and 50% of CPU resources in the Database Tier. Fault Tolerance The reference architecture is fault tolerant at every level. With clusters at the web, application, and database tier, you may suffer a catastrophic hardware failure of any node and continue to service users with little performance degradation. The depicted reference architecture represents the minimum deployment units to ensure proper fault tolerance within a single data center. You may increase the number of servers within each tier according to your load patterns and achieve a multiplier effect in the number of users the deployment can support in a fault tolerant fashion. Multi-data-center fault tolerance architectures are not provided as part of the reference architecture. Scalability Liferay Engineering s testing has shown LPEE to scale linearly. Thus, if you know a single application server supports X virtual users and assuming sufficient database and web server resources, you may calculate the total number of application servers required. 3

6 Portal Tuning Guidelines When tuning your LPEE, there are several factors to take into consideration, some specific to Liferay Portal, while others are concepts that apply to all Java and Java enterprise applications. Application Server Tuning Although the actual settings may differ, the concepts are applicable across most application servers. We will use Tomcat as an example to demonstrate application server tuning concepts. You should also consult your application server provider s documentation for additional specific settings that they may advise. Deactivate Development Settings in the JSP Engine Most application servers have their JSP Engine configured for development mode. Liferay recommends deactivating many of these settings prior to entering production: Development Mode this will enable the JSP container to poll the file system for changes to JSP files. Mapped File generates static content with one print statement versus one statement per line of JSP text. Generate String as Char Array generates strings as static character arrays to relieve excess garbage collection. Tomcat 6.0.x and 7.0.x In the $CATALINA_HOME/conf/web.xml, update the JSP servlet to look like the following: <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.jspservlet</servlet-class> <init-param> <param-name>development</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>mappedfile</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>genstraschararray</param-name> <param-value>true</param-value> </init-param> <load-on-startup>3</load-on-startup> </servlet> 4

7 Thread Pool Each incoming request to the application server consumes a worker thread for the duration of the request. When no threads are available to process requests, the request will be queued waiting for the next available worker thread. In a finely tuned system, the number of threads in the thread pool should be relatively balanced with the total number of concurrent requests. There should not be a significant amount of threads Liferay Engineering recommends setting this initially to 50 threads and then monitoring it within your application server s monitoring consoles. You may wish to use a higher number (e.g. 250) if your average page times are in the 2-3s range. Tomcat 6.0.x and 7.0.x In Tomcat, the thread pools are configured in the Connector element in $CATALINA_HOME/conf/server.xml. Further information can be found in the Apache Tomcat documentations (http://tomcat.apache.org/tomcat-6.0-doc/config/http.html). Liferay Engineering used the following configuration during testing: <Connector port= 8019 maxhttpheadersize= 8192 maxthreads= 50 minsparethreads= 50 maxsparethreads= 50 enablelookups= false acceptcount= 100 redirectport= 8443 protocol= AJP/1.3 connectiontimeout= disableuploadtimeout= true URIEncoding= UTF-8 /> Additional tuning parameters around Connectors are available, including the connection timeouts and TCP queue. You should consult the appropriate Tomcat documentation for further details. Database Connection Pool The database connection pool is generally sized at roughly 20-30% of the thread pool size. The connection pool provides a connection whenever LPEE needs to retrieve data from the database (e.g. user login, etc). If this size is too small, requests will queue in the server waiting for database connections. However, too large a setting will mean wasting resources with idle database connections. Tomcat 6.0.x and 7.0.x In Tomcat, the connection pools are configured in the Resource elements in $CATALINA_HOME/conf/ Catalina/localhost/ ROOT.xml. Liferay Engineering used the following configuration during testing: <Resource auth= Container description= Portal DB Connection driverclass= com.mysql.jdbc.driver maxpoolsize= 75 minpoolsize= 10 acquireincrement= 5 name= jdbc/liferaypool 5

8 user= XXXXXX password= XXXXXXXXX factory= org.apache.naming.factory.beanfactory type= com.mchange.v2.c3p0.combopooleddatasource jdbcurl= jdbc:mysql://someserver:3306/lportal?useunicode=true&characterencoding=utf-8&usefastdatep arsing=false /> In this configuration, we have a maximum of 75 connections in the pool and starting with 10. Should all 10 be used, the pool will automatically add 5 additional connections. You may choose from a variety of database connection pool providers, including DBCP, C3P0, and Tomcat (if deploying to Tomcat 7). Java Virtual Machine Tuning Tuning the JVM primarily focuses on tuning the garbage collector and the Java memory heap. These parameters look to optimize the throughput of your application. We used the Sun 1.6 JVM for the reference architecture. You may also choose the IBM JVM and Oracle s JRockit JVM. Garbage Collector Choosing the appropriate garbage collector will help improve the responsiveness of your LPEE. Liferay Engineering recommends using the concurrent low pause collectors: -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled - XX:ParallelGCThreads=16 -XX:+CMSCompactWhenClearAllSoftRefs - XX:CMSInitiatingOccupancyFraction=85 -XX:+CMSScavengeBeforeRemark - XX:+CMSConcurrentMTEnabled -XX:ParallelCMSThreads=2 Other garbage collectors include a concurrent throughput collector. You may find more information on garbage collector heuristics at Java Heap When most people think about tuning the Java memory heap, they think of setting the maximum and minimum memory of the heap. Unfortunately, you require far more sophisticated tuning for the heap to obtain optimal performance, including tuning young generation size, tenuring durations, survivor spaces, and many other JVM internals. For most systems, Liferay recommends starting with at least the following VM parameters: -server -XX:NewSize=700m -XX:MaxNewSize=700m -Xms2048m -Xmx2048m -XX:MaxPermSize=200m -XX:SurvivorRatio=6 XX:TargetSurvivorRatio=90 XX:MaxTenuringThreshold=15 On servers with 8+GB of memory, Liferay recommends starting your performance tuning with the following settings: -server -d64 -XX:NewSize=3072m -XX:MaxNewSize=3072m -Xms6144m -Xmx6144m -XX:PermSize=200m -XX:MaxPermSize=200m -XX:SurvivorRatio= XX:TargetSurvivorRatio=0 -XX:MaxTenuringThreshold=0 -XX:+UseParNewGC -XX:ParallelGCThreads=16 6

9 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+CMSCompactWhenClearAllSoftRefs -XX :CMSInitiatingOccupancyFraction=85 -XX:+CMSScavengeBeforeRemark -XX:+CMSConcurrentMTEnabled -XX:ParallelCMSThreads=2-XX:+UseLargePages -XX:LargePageSizeInBytes=256m -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:-UseBiasedLocking -XX:+BindGCTaskThreadsToCPUs -XX:+UseFastAccessorMethods The above settings should formulate a starting point for your performance tuning. Each system s final parameters will vary due to a variety of factors. You may find the definitive list of Sun JVM options are located at: Monitoring GC and JVM Although the previously introduced parameters give you a good start to tuning your JVM, you must monitor GC performance to ensure you have the best settings to meet your needs. There are several tools to help you monitor Sun JVM performance including: Visual VM (http://visualvm.dev.java.net) This tool provides a centralized console for viewing Sun JVM performance information, including garbage collector activities. Figure 2 - Visual VM s Visual GC 7

11 Portal Tuning Parameters LPEE ships with many parameters already optimized for performance. However, depending on your specific use case, you may wish to tune additional settings. Unless otherwise stated, you may tune these parameters in your portal-ext.properties configuration file. 2 Servlet Filters LPEE ships with a large collection of servlet filters to implement features like CAS SSO and NTLM SSO. You may choose to remove the following filters: GZIP Filter used for GZIP compression of the generated pages. You should allow the Apache Web Server perform this operation. To deactivate, add the following to portal-ext.properties com.liferay.portal.servlet.filters.gzip.gzipfilter=false Strip Filter used to remove extraneous whitespaces in generated HTML. Web servers should be used to handle this processing. To deactivate, add the following to portal-ext.properties com.liferay.portal.servlet.filters.strip.stripfilter=false SSO CAS Filter used to implement single sign-on using CAS. If you rely upon a different solution, you may deactivate. To deactivate, add the following to portal-ext.properties com.liferay.portal.servlet.filters.sso.cas.casfilter=false SSO NTLM Filter used to implement single sign-on using NTLM. If you rely upon a different solution, you may deactivate. To deactivate, add the following to portal-ext.properties com.liferay.portal.servlet.filters.sso.ntlm.ntlmfilter=false SSO OpenSSO Filter used to implement single sign-on using OpenSSO. If you rely upon a different solution, you may deactivate. To deactivate, add the following to portal-ext.properties com.liferay.portal.servlet.filters.sso.opensso.openssofilter=false SharePoint Filter used to implement enable the portal to understand SharePoint protocols for integration with MS Office applications. To deactivate, add the following to portal-ext.properties com.liferay.portal.sharepoint.sharepointfilter=false Valid HTML Filter used to ensure HTML generated from Portal are XHTML compliant. To deactivate, add the following to portal-ext. properties com.liferay.portal.servlet.filters.validhtml.validhtmlfilter=false Prior to LPEE 6.1, an alternative way to further increase performance is to modify the web.xml for the portal and remove these filters. However, Liferay Engineering has simplified this process such that deactivation within the portal properties will provide the same performance gains. 2 In Tomcat, you may change settings in portal.properties by placing a portal-ext.properties in $CATALINA_HOME/webapps/ROOT/WEB-INF/classes. We recommend you consult the Liferay Portal Administration Guide for other application servers. 9

12 User Session Tracker LPEE enables administrators to view the activities of the users currently using the portal. While useful for troubleshooting, this feature may decrease performance. In general, we recommend deactivating this feature. You may do so by adding the following to portal-ext. properties: session.tracker.memory.enabled=false Counter Increment LPEE uses an internal sequence generator for generating object ids. Increasing the increment size of this counter will reduce the number of times it must communicate with the database to reserve IDs. We recommend setting this number at roughly 2000, depending on the load of your system. You may do so by adding the following to portal-ext.properties: counter.increment=2000 Portlet CSS LPEE provides you the ability to assign custom style sheets within your portlets. You may choose to deactivate this feature, especially if you are not planning on deploying any custom portlets in LPEE. You may do so by adding the following to portal-ext.properties: portlet.css.enabled=false Session Timeout With most web applications, the default session timeout is configured for 30 minutes. Although this may be friendly for the user, it does create added resource consumption for the application. LPEE provides several techniques to help you reduce the session timeout for idle users while minimally impacting usability. To reduce the lifespan of the session, you should modify the web.xml 3 and change the timeout: <session-config> <session-timeout>10</session-timeout> </session-config> Portal Caching WARNING: Care should be taken when tuning caching. The size of the cache will have direct impact to the amount of memory your application server has to work with. The larger the cache, the less memory available for processing requests. If your application caching requirements exceed what the out of the box, in-process provides in scalability, Liferay recommends investigating the use of Terracotta as a clustered, out of process cache. Liferay Portal relies upon both content and object caching to minimize database interaction and excessive object creation. Out of the box, the portal leverages EHCache for its caching needs. You may configure additional caches including Terracotta, OSCache, Oracle Coherence Cache, etc. For the purposes of our discussion, we will focus on the out-of-the-box EHCache. 3 On Tomcat, the LPEE web.xml is located in $CATALINA_HOME/webapps/ROOT/WEB-INF/web.xml 10

13 To monitor the caches, you will need to rely upon the JMX Console. 4 In the proceeding figure, we see the JMX Console view for monitoring a cache used to store user information: CacheHits displays the number of requests that successfully retrieved from the cache rather than going to the database. This includes objects stored in memory and stored on disk. CacheMisses displays the number of requests that could not find its object in cache and thus had to retrieve from the database. InMemoryHits displays the number of requests that successfully retrieved from the in memory cache. This does not include requests that triggered retrievals from on disk storage. ObjectCount the total number of objects in cache OnDiskHits the total number of requests that could not find their objects in memory, but successfully located the objects on the local file system. This is only applicable if you have enabled cache overflow to disk. 5 Figure 4 - Monitoring Liferay Data Caches By default, Liferay Portal s cache configuration uses the memory store and allows for a maximum of 10,000 elements. Although using a disk store may increase the size of the cache, Liferay does not recommend this approach due the increased dependency upon disk IO operations. Let us use the user cache as our tuning example. After monitoring, you have determined that the user cache requires tuning due to the number of cache misses. To tune the cache: 1. Update your portal-ext.properties and specify your own cache configuration files: ehcache.single.vm.config.location=/ehcache/custom-single-vm.xml ehcache.multi.vm.config.location=/ehcache/custom-multi-vm.xml 4 Future releases of Liferay Portal Enterprise will have an Enterprise Console that will allow management and monitoring of a Liferay Portal deployment, including cache and memory monitoring. 5 Cache overflow to disk means allow Ehcache to serialize (write) objects to the local file system. This is akin to using virtual memory page at the operating system level. 11

14 2. Copy and rename the liferay-single-vm.xml and liferay-multi-vm.xml files to custom-single-vm.xml and custom-multi-vm.xml files respectively In the custom-multi-vm.xml, if an entry already exists for the user cache, you may simply change the maxelementsinmemory. If an entry does not exist, you should add the following: <cache name= com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.userimpl maxelementsinmemory= 1000 eternal= false timetoidleseconds= 3600 overflowtodisk= false /> The above configuration will set the user cache to contain at most 1000 elements and the cached values will remain in memory for 3600 seconds (1 hour) or if replaced by a newer element. Additional portal caches of interest include: com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.accountimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.contactimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.groupimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.layoutimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.layoutsetimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portal.model.impl.resourceimpl The following caches may be of interest, depending on the features you are leveraging in the product: com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.blogs.model.impl.blogsentryimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.wiki.model.impl.wikipageimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.messageboards.model.impl.mbcategoryimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.messageboards.model.impl.mbthreadimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.journal.model.impl.journalarticleimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.journal.model.impl.journalstructureimpl com.liferay.portal.kernel.dao.orm.entitycache#com.liferay.portlet.journal.model.impl.journaltemplateimpl Portal Cache Replication Liferay Portal has hundreds of object caches that require event cached object replication or cache event replication. By default, Ehcache uses a thread-per-cache replication algorithm which may introduce additional overhead. For Enterprise Edition customers, Liferay ships with an enhanced algorithm which uses more efficient thread pooling for cached object and event replication. To configure the portal to use this algorithm, please download and install the ehcache-cluster-web module from the Liferay Customer Portal and configure the following properties: cluster.link.enabled=true ehcache.cluster.link.replication.enabled=true 6 We suggest you deploy these files to the web application s WEB-INF/classes. For instance, if deploying Liferay in the Tomcat application server, you should place the files in $CATALINA_HOME/webapps/ROOT/WEB-INF/classes. 12

15 Liferay Message Bus WARNING: This is an advanced configuration and you should modify sparingly. The Liferay Message Bus has been tuned to handle most scenarios. Liferay Portal leverages asynchronous messaging, via the Liferay Message Bus, for many of its services like mail and indexing. The bus provides a loosely coupled, pluggable architecture that helps improve user experience by performing system tasks (e.g. notifications) in the background. Liferay recommends monitoring and tuning the message bus according to your use case. You may monitor message bus statistics via the JMX Console discussed previously. Figure 5 - Monitoring Liferay Message Bus In above picture, we see the statistics for the messaging destination liferay/mail : ActiveThreadCount displays the current number of active worker threads for this destination CurrentThreadCount displays the total number of worker threads LargestThreadCount displays the maximum number of worker threads. This is the high water mark reached when the destination was the busiest MaxThreadPoolSize displays the maximum number of worker threads allowed for this destination. The destination will not allocate more than this number of threads to service requests. 13

16 MinThreadPoolSize displays the minimum number of worker threads that should be started when the destination is activated PendingMessageCount displays the number of messages waiting for worker threads to deliver them SentMessageCount displays the total number of messages delivered via this destination In tuning the Liferay Message Bus, you should monitor the PendingMessageCount and the ActiveThreadCount statistics. If you do not have sufficient worker threads allocated, you will see a high PendingMessageCount, implying you should allocate more threads to deliver the message. However, you should be conservative in allocating additional threads as too many threads may cause performance degradation. To change the default settings, you may modify the messaging-spring.xml bundle with the portal. To continue with our example, let s assume we want to increase the number of threads for the liferay/mail destination. We would modify the settings in messaging-spring.xml to: <bean id= destination.mail class= com.liferay.portal.kernel.messaging.paralleldestination > <property name= name value= liferay/mail /> <property name= maximumqueuesize value= 100 /> <property name= workercoresize value= 10 /> <property name= workersmaxsize value= 15 /> </bean> The above settings will configure the liferay/mail destination to have at minimum 10 and no more than 15 worker threads to service requests. 14

17 Summary In the preceding sections, we outlined the steps to design a fully fault-tolerant Liferay Portal Enterprise Edition deployment. The architecture described builds a solid foundation for future growth. In addition, the Liferay Engineering team has shared several key factors in successfully tuning a LPEE deployment. Although these parameters has wide application and has withstood many different load testing scenarios, Liferay Engineering recommends continuously monitoring your LPEE deployment to ensure long-term performance. Disclaimer Liferay can only give you an initial tuning recommendation based on benchmarks that have been performed on the core Portal product. It is up to you as system architects and business analysts to come up with the utilization scenarios that your system will need to service. It is your responsibility to run the appropriate load tests on your system before production deployment, so that you can identify significant bottlenecks due to custom applications/portlets, and other unforeseen system and network issues, and implementing the appropriate configurations. Please use this document and the Liferay Portal Performance whitepaper (http://www.liferay.com/documentation/additional-resources/ whitepapers) as mere guides in sizing your system and procuring your hardware. Moving Forward Liferay Enterprise Edition Support Liferay Enterprise Edition ensures stability and reliable technical support for your Liferay Portal installation and your organization s team. Including a customer portal, product bulletins, security alerts, plus the support of over 100 partners worldwide. Liferay Professional Services Liferay Professional Services can help you in the design, planning, and implementation of your system. Performance tuning consultation is also available. Contact for more information. 15

18 LIFERAY, INC. is the provider of leading enterprise open source portal and collaboration software products, used by major enterprises worldwide, including Allianz, AutoZone, Benetton Group, Cisco Systems, Lufthansa Flight Training, The French Ministry of Defense, and the United Nations. Liferay, Inc. offers professional services, technical support, custom development, and professional training to ensure successful deployment in the most demanding IT environments. 2012, Liferay, Inc. All rights reserved

White Paper NetIQ Access Manager 4.1 Performance and Sizing Guidelines Performance, Reliability, and Scalability Testing Revisions This table outlines all the changes that have been made to this document

Liferay Portal Performance Best Practices Samir Bhatt Chapter No. 3 "Configuration Best Practices" In this package, you will find: A Biography of the author of the book A preview chapter from the book,

Oracle WebLogic Server 11g Administration This course is designed to provide instruction and hands-on practice in installing and configuring Oracle WebLogic Server 11g. These tasks include starting and

Informatica Master Data Management Multi Domain Hub API: Performance and Scalability Diagnostics Checklist 2012 Informatica Corporation. No part of this document may be reproduced or transmitted in any

UPGRADING TO XI 3.1 SP6 AND SINGLE SIGN ON Chad Watson Sr. Business Intelligence Developer UPGRADING TO XI 3.1 SP6 What Business Objects Administrators should consider before installing a Service Pack.

WHITE PAPER Domo Advanced Architecture Overview There are several questions that any architect or technology advisor may ask about a new system during the evaluation process: How will it fit into our organization

Mission-Critical Java An Oracle White Paper Updated October 2008 Mission-Critical Java The Oracle JRockit family of products is a comprehensive portfolio of Java runtime solutions that leverages the base

Objectives At the end of this chapter, participants will be able to understand: Web server management options provided by Network Deployment Clustered Application Servers Cluster creation and management

WebSphere Server Administration Course Chapter 1. Java EE and WebSphere Overview Goals of Enterprise Applications What is Java? What is Java EE? The Java EE Specifications Role of Application Server What

MEASURING WORKLOAD PERFORMANCE IS THE INFRASTRUCTURE A PROBLEM? Ashutosh Shinde Performance Architect ashutosh_shinde@hotmail.com Validating if the workload generated by the load generating tools is applied

Best Practice - Tomcat Performance Tuning for Pentaho This page has intentionally been left blank. Contents Overview... 1 Tuning Tomcat for Performance... 2 Choose the Right Connector... 2 Set the Right

WebLogic Server Course Following is the list of topics that will be covered during the course: Introduction to WebLogic What is Java? What is Java EE? The Java EE Architecture Enterprise JavaBeans Application

Holistic Performance Analysis of J2EE Applications By Madhu Tanikella In order to identify and resolve performance problems of enterprise Java Applications and reduce the time-to-market, performance analysis

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material,

LABVANTAGE Architecture 2012 LABVANTAGE Solutions, Inc. All Rights Reserved. DOCUMENT PURPOSE AND SCOPE This document provides an overview of the LABVANTAGE hardware and software architecture. It is written

Cloud Based Application Architectures using Smart Computing How to Use this Guide Joyent Smart Technology represents a sophisticated evolution in cloud computing infrastructure. Most cloud computing products

& JavaEE Platform Monitoring A Good Match? Company Facts Jesta Digital is a leading global provider of next generation entertainment content and services for the digital consumer. subsidiary of Jesta Group,

E-mail Listeners 6 E-mail Formats You use the E-mail Listeners application to receive and process Service Requests and other types of tickets through e-mail in the form of e-mail messages. Using E- mail

Introduction By leveraging the inherent benefits of a virtualization based platform, a Microsoft Exchange Server 2007 deployment on VMware Infrastructure 3 offers a variety of availability and recovery

CA Identity Governance Implimentation Guide 12.6.02a This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is

Aplicações empresariais de elevada performance com Oracle WebLogic e Coherence Alexandre Vieira Middleware Solutions Team Leader Which FOUNDATION? How to have CONTROL? How to run FASTER? Which FOUNDATION?