|
|
|
|
|
|
Factors Affecting Performance
Application throughput is the amount of work processed by a system in a given period of time. A typical measurement of application throughput is the number of transactions (usually, requests) processed per second. This topic describes factors that can influence how much system hardware capacity will be required to support throughput requirements.
This topic includes the following sections:
General Web Application Factors
The following paragraphs describe general factors that could impact your Web application's performance.
Complex Page Layouts
Intricate table layouts and other complex HTML can cause a perceived wait on the client after the files are transmitted and the browser determines how to render the page. Simple pages render more quickly.
Image Content
More images require more downloading from the server, lengthening the time it takes for a Web page to complete rendering. The size of each image file is also a factor affecting performance. Although there may only be a few, large image files can slow down delivery of a Web page. Keep the number of images you use on a page to a minimum, and be sure those you do use are a reasonable size. Additionally, the location of those images from a network perspective is important. For instance, images should not need to traverse firewalls before arriving at a user's browser.
Clustered Session Replication
Presently, a conservative approach is used for failover of HTTP session data. All client states are contained in the HTTP session, which provides a high degree of failover. In other words, the failure of a server in a cluster will only abort the current transaction, and the user session will be continued with no loss of data. (However, if the HttpSession contains an attribute that is not serializable, then the replication will not happen.)
Secure Sockets Layer (SSL)
The use of Secure Sockets Layer (SSL) in communication from a user's Web browser to a server or from server to server can affect overall throughput. SSL should be used when encryption of sensitive data is required while in transit or when strong server authentication is required. However, SSL should not be used unless it is absolutely needed.
WebLogic Server (WLS) Factors
Because the WebLogic Commerce Server, Personalization Server with Portal Framework, and Campaign Manager products run on the BEA WebLogic Server (WLS), it is expected that factors impacting the performance of WLS will also impact the performance of the WebLogic Commerce and Personalization Servers and Campaign Manager.
Campaign Manager for WebLogic Factors
The following are factors affecting performance of Campaign Manager.
Referencing Events
Always make scenario rules dependent on a particular event. This allows the Campaign Manager to make some optimizations based on the event types referenced in the scenario rules.
Avoiding Firing Extraneous Events
Whenever possible, avoid firing any extraneous events. The Campaign Manager has to listen to all events. Use events to signify important occurrences on the site.
WebLogic Commerce Server (WLCS) Factors
The following paragraphs describe the factors specific to the BEA WebLogic Commerce Server that could potentially impact performance.
Cache Settings
The BEA WebLogic Commerce Server product catalog makes use of two in-memory caches for products and categories. The settings assigned to these caches can greatly affect the performance of an installation.
In general, most catalogs (except the largest) should cache all of the items and categories that will be accessed with any degree of frequency. For the purposes of capacity planning, the cache settings affect the amount of RAM allocated directly to these cache instances.
Note: For more information about these settings, see "Improving Catalog Performance by Optimizing the Catalog Cache" within "Catalog Administration Tasks" at http://download.oracle.com/docs/cd/E13210_01/wlcs/docs35/catalog/admin.htm.
Products
For exact product memory requirements, browse the WLCS_PRODUCT table in the database to determine the average number of characters used by each field in the database.
Then, multiply the result by the number of products in the database. The final result is the number of bytes of RAM that are required to cache all of the products. For a conservative estimate based on middle-of-the-road usage for every field in the schema, use 3200 bytes per product. For an example of these calculations, see Example of Calculating the Necessary RAM.
Note: Use four characters for dates and multiply character fields by two to account for Unicode encoding used by Java.
Categories
The fields considered in the calculations of category memory requirements are located in the WLCS_CATEGORY table in the database. However, the caching scheme for categories is more complex. In addition to the category data, the category's position in the hierarchy is also cached. This makes it more important to cache categories than items. Specifically, the following information is stored about each category and is cached:
Note: Only primary keys are cached.
To arrive at the RAM requirement for category caching, add the data associated with the category as well as the space required by the hierarchy information (that is, the number of entries multiplied by the size of the appropriate key). For an example of these calculations, see Example of Calculating the Necessary RAM.
Example of Calculating the Necessary RAM
Suppose a site has 100,000 product items. The items are in a hierarchy with 15 top-level categories, 225 second-level categories (each category has 15 subcategories), and 3375 third-level categories (again, each category has 15 subcategories) for a total of 3615 categories. For simplicity, assume that the products are scattered evenly across all 3615 categories, and that each product exists in two different categories (56 items/category). Further, assume that product keys and category keys are each 10 characters long and will therefore occupy 20 bytes of RAM each. Lastly, each category's database data occupies 1000 bytes, and each product item occupies 3000 bytes.
Product RAM Calculation
3000 bytes/item * 100000 items = 300 MB RAM
Therefore, 300 MB RAM is required to cache the whole catalog (which is recommended if possible).
Category RAM Calculation
1000 bytes/category * 3615 categories = 3.6 MB RAM
Therefore, 3.6MB RAM is required to cache the data.
Category Hierarchy RAM Calculation
RAM Totals
300 MB (product) + 3.6 MB (category data) + 233 MB (hierarchy) = 536.6 MB
Therefore, approximately 537 MB is required for catalog caching.
Catalog Size
The number of product items in the catalog tables and their corresponding attributes can have a significant effect on response time, especially when querying the catalog and making product recommendations. Because searching for and recommending products are key aspects of the browsing experience, it is important to ensure that your database is large enough to handle this product information; a slow database can limit performance of the whole application.
Catalog Update Frequency
When updating the product catalog directly in the database, it is recommended that the product item cache be disabled to prevent stale data. This is particularly true if category information is being changed. Running a server with the catalog cache disabled will place a greater burden on the Commerce Server's database. This performance factor should be measured and planned for, based on the frequency of category and product updates. The cache can be left enabled if the updates are done through the server APIs, but the performance of that approach should be tested with a fully populated catalog.
Payment Settings
Settlement of commerce transactions can be done either in real-time or in batch mode (via the Administration Tools). The business model typically dictates which approach is taken. The real-time (online) approach will result in longer response times because the settlement process typically requires a network connection to a payment service. However, this approach guarantees that customers only pay for goods received. Batch settlement enables faster response to customers, but requires some back office processing to perform settlement.
Pipeline Session Data
At some point, your application will probably require that objects be stored in a Pipeline session. A large amount of data stored in the session (for example, search results) may affect performance and reduce the overall scalability of the application for clustered environments.
Note: For other factors that may affect application scalability, see Location of Java Virtual Machines (JVMs).
Deployment
In general, networked applications should be near (in a network sense) to the resources they utilize. If possible, for example, the WebLogic Server instances should be on the same network segment as the database.
Clustering your deployment is preferred, both for failover and for good performance. There are, however, some factors that can heavily influence the effectiveness of a clustered deployment. In particular, the location of the Web server's proxy plugin (relative to the cluster) is the most important factor.
In the preferred configuration, the Web servers between the external and internal firewalls (the DMZ) proxy requests for dynamic content served by WLS from within the internal network. The HTTP servers—not the application servers behind the firewalls—serve static content (HTML, GIFs, and so on).
This deployment is the highest performing as well as the most secure configuration. The network traffic between the proxy plugin is coarse-grained HTTP instead of the fine-grained RMI traffic used by EJBs, so traffic across the firewall is minimized. The fact that the plugin is running in the DMZ also minimizes the amount of logic executing in this area, and makes the system more secure.
Note: Cluster configurations other than the one described here will work, but with significant security and performance implications.
Location of Java Virtual Machines (JVMs)
Although clustered environments offer benefits in terms of both load balancing and failover, it is important to consider the location of clustered nodes as they relate to application scalability. If a single machine is assigned multiple IP addresses, scalability is improved because replication of HTTP session data does not require traversing the network. However, this obviously is less desirable where failover is critical (for example, in situations where customers should never lose their shopping cart). If you choose to run Java Virtual Machines (JVMs) on different machines to ensure failover, the scalability of your application might be negatively affected.
WebLogic Personalization Server with Portal Framework (WLPS) Factors
The following paragraphs describe the factors specific to the BEA WebLogic Personalization Server that can have an impact on performance.
Caching Methods: CachedProfileBean
If you are getting and setting user properties in a servlet, use the methods of com.beasys.commerce.user.jsp.beans.CachedProfileBean instead of com.beasys.commerce.axiom.contact.User so that you can take advantage of caching. Even the first invocation of CachedProfileBean.getProperty() is significantly faster than User.getProperty(). Subsequent invocations of CachedProfileBean.getProperty() are orders of magnitude faster. The CachedProfileBean is what the JSP tags use.
While using CachedProfileBean is significantly faster for getting properties, it can be slower than the User object for setting properties for the following reasons:
We advise against using the User.setProperty method, especially for highly shared entity beans, since deadlocks may occur. For example, avoid using User to set a property for a user that has a Group specified as a successor; Groups are highly shared entity beans, increasing the chance of deadlock.
You generally should not mix User.setProperty() and CachedProfileBean.getProperty(). Since User.setProperty() updates the database but not the cache, you may be left with a dirty cache.
Our best advice is to stick with CachedProfileBean, but if you are doing a series of set statements, wrap all of the set statements in a transaction (such as javax.transaction.UserTransaction). This approach has two benefits:
Other notes on CachedProfileBean:
java -Dcommerce.properties=weblogiccommerce.properties MyT3Client
Accessing the Database
The number of times the database is accessed while generating a portlet or Web page can have a significant effect on application performance. If this number is kept low, performance might benefit. Alternatively, numerous queries to the database can hurt performance.
Application Complexity
Complex applications have the potential to incur performance bottlenecks. For example, an application that must access a database, two mainframes, an LDAP server over SSL, and a secondary Web server is going to have more potential for degraded performance than an application that simply queries a single, local database. Designers of complex applications must carefully consider all potential bottlenecks and address them with appropriate solutions, such as a data caching strategy.
Content Management Changes in WLPS 3.5
The following changes were made for WebLogic Personalization Server 3.5 that should increase performance.
Note: The useSoftHashMap setting is not recommended on Solaris.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|