Archive for Performance

Automate Your Web Page Testing

By Denise Kalm | Industry Expert

A new, clean web page isn’t built in a day — it requires major testing before going live. Web pages are software, and software is prone to bugs. Problems with your pages can seriously affect your line of business, and the wide visibility of a web page harbors the risk of damaging your brand when mistakes happen. (And they do.) Mistakes in this arena are deadly not only because customers might seek out other business: Public mistakes are just plain embarrassing!

Though most application software goes through complex automated QA and load testing, too often web pages don’t get the same diligence and attention, because they “look just fine.” You may manually walk through various options, but the “if it ain’t broke, don’t fix it” mentality is tempting. It’s possible you’ve known for years that your company needs an automated tool, but budget constraints have placed it out of reach for except the largest companies. But now small startups are working harder and getting smarter, and small companies are accordingly offering creative, affordable solutions. In short, you can no longer afford not to evaluate your automation needs.

So what kinds of questions should you ask yourself while evaluating? “How repeatable are your manual tests?” “How long does each test take?” Automating the process allows you to run tests repeatedly as you develop the web pages without impacting the development schedule. For web applications, tests need to be run on all operating systems and hardware types your customers might use — a complicated, unwieldy process when performed manually. Automated test scripts ensure that you cover all the bases, freeing up time and money that you can then devote to other areas.

You’ll also have the option to create more tests than you would ever want to execute manually. (Remember: The more you test, the more reliable your software will be.) You not only want to test the ideal way a customer works with your application; you also need to run tests that’ll check when things go wrong. It is essential to detect where, how, and why your application isn’t handling a situation correctly. Once your solution is in place, you can have the product report on in-flight, transaction processing steps to see contents of tables and files, and the memory to understand and correct problems.

So what does automation mean for you?

  1. Automation means accuracy. Each run will be exactly the same as the last, and every important aspect will be documented. Unless you hire out, developers in small shops end up doing the testing, which wastes valuable company resources (and is hardly fun for them).
  2. Automation means scale. No one can bring together hundreds or thousands of users to test the capacity of a system and detect potential issues, such as out-of-sequence database updates. Only an automation solution can test the limits of your application as thoroughly as if it were running live.
  3. Automation means a happier and more productive team. When developers and QA can do what they love instead of what they find tedious, everyone smiles more. Simple as that.

What are the steps involved in automation?

The first step is deciding what tests to run — the most obvious of which are unit, functional, regression and load testing. Unless this is a brand new application, you’ll also need to conduct regression testing to ensure you haven’t broken anything in the existing code. Your application may have other needs, so be sure to have a complete list before you search for a product.

Once you know this, you can prepare a list of requirements (or RFP) to present to a list of vendors, such as supported platforms, scripting languages, the ability to record and/or replay, and kinds of testing they offer. Vendors must, of course, be able to test against all the common browsers, but they’ll also need to test all the popular mobile platforms.

This may sound overwhelming, but CM First can help!

We at CM First can help you develop efficient ways to automate testing of your browser, mobile, green screen, and client-server applications with industry-leading products coupled with best practices training and mentoring. We are particularly experienced with applications developed with CA Plex and CA 2E, but we are not limited to applications built with those products. (Anything that has an interface can be automatically tested, including packages like Office and Salesforce.)

In sum, running tests early in the development cycle expedites the process of getting your working product to market. Let CM First help smooth the transition from manual to automated so you stress less and profit more.

When will you start automating?

WebClient Runtime Framework Explained

At application runtime, your WebClient application operates under the control of the WebClient i+ Server, also known as the WebClient i+ Runtime Framework. The WebClient i+ Runtime Framework is implemented as an extension of a standard J2EE Servlet, and provides all the services necessary to deploy your WebClient application as secure, high performance web applications. The servlet model is powerful – fast performance and ease of use make it the architecture of choice over older mechnisms like CGI. For example, servlets can be utilized in high performance, load balanced configurations utlizing multiple web server instances

The WebClient Runtime Framework comes in two editions – the ADC Server edition and the Websydian Server+ edition. There is no difference between the editions, except that the Websydian edition is compatible with WSE applications and can run classic Websydian applications.

The WebClient i+ Runtime Framework consists of the following services:

CA Plex Application Connection

The WCi+ server connects the browser Ajax presentation layer to the business logic generated from your CA Plex action diagrams. For example, user interactions like right-clicking on a grid or selecting a value from a combo box are communicated as events to the CA Plex applications. And corresponding, action diagram statements that affect the presentation layer like updating values or refreshing the grid are communicated to the browser.

Session Management

As is standard for web applications, the WCi+ server creates and manages sessions for each web site user. Session tracking is a mechanism that is used to maintain state about a series of requests from the same user (that is, requests originating from the same browser) across some period of time. Typical session data that can be of interest is the authenticated user (if any), the URL used to start the web application, the session id, method (GET or POST), query parameters, etc. For more information on tracking sessions in WebClient, please visit this blog post:

The WCi+ server also manages session timeouts. For more information on setting inactivity timeouts, please visit this wiki page:

Logging and Tracing

The WCi+ Server logs application events of interest, including errors. See the setting for details. The log can be configured to output performance metrics, which is useful when optimizing response time of your web applications. See servlet.statistics.level in the documentation for more details on this.

WCi+ can also display specific error pages when an error occurs, via the servlet.errorpage.url setting.

Calling WebClient Applications from an External Application

The WCi+ server can respond to requests to show web pages from external applications or packages, also called deep linking. With deep linking, parameters can also be passed into the web request. See the user manual for more information.


The WCi+ Server manages the licensing process, tracking how many concurrent users are logged in against the tier of server you have purchased. If you exceed the number of users you have licensed, error messages will be generated in the log.



WebClient Web Application Server Listener

To add an application server web session listener to your WebClient application, ensure that this  XML fragment is present under the web-app element in your web.xml.


When the listener is installed, then application clean-up will occur immediately when the session times out (as determined by the application server’s timeout settings). The user closing their browser window will also trigger a session clean-up. This is particularly important for WebSphere implementations.

Deploying WebClient Applications using Tomcat/Apache with SSL

There are benefits to running secure production WebClient/Websydian applications under a combination of both Tomcat and Apache. This configuration can be the highest performance option, and can be run under SSL for security. Tomcat and Apache are both free, open source software that are proven in high performance production environments. While lacking some of the management features of advanced web application servers like IBM Websphere, the reduced cost mitigate this in many cases.

The following diagram depicts a high-level view of the architecture:

There are two major components in the setup: the Apache web server and a Tomcat servlet container.

Apache is a fully-featured web server, meaning it has the ability to serve static pages to users while offering a variety of options that provide value in web environments. Strictly a web server, it has no ability to serve dynamic pages, in other words, content that changes with user input or other sources of data. Dynamic pages might be implemented with Apache by using different mechanisms like modules to allow execution of languages like PHP and Perl. In this scenario, the mod_jk module is used to connect Apache with an existing Tomcat installation, obtaining the equivalent result of enabling Apache to serve dynamic pages but with help from an external service.

A web client is defined as a single user requesting content from a web server. The web server will handle requests and return a response for each client’s request. This is the basic interaction between clients and servers in web applications. In this setup, web clients will be able to establish a secure communications channel between them and the server by using the HTTPS (HTTP over SSL) protocol. HTTPS support is provided by mod_ssl, an extension module for the Apache Web Server.

View all the details on the setup here.

WebClient Benchmarking

Many web developers are interested in performance of their production web applications – as well they should be. Performance under load can be quite different than performance in a development environment or on your personal workstation. To give some guidance on this, we have created a benchmark document. In this document, the developer can see how WebClient performs under simultaneous load with a simple application, and more importantly get information on how to set up a custom benchmarking scenario for your applications. This can be done use free tools like OpenSTA, or more sophisticated tools like the Worksoft line of performance simulation.

One key item is determining the number of virtual users to simulate. This handy calculator can potentially help. Usually the number of active virtual users is much less than the number of logged in users, because users are not constantly active in many business appplications.

We hope this information helps you. Please contact us at if we can assist further.

© 2013 CM First Group - All rights reserved