What is Silk Performer?
Silk Performer provides advanced facilities for running multi-user tests to validate an application’s performance under different load conditions. It provides on-demand cloud based load generation facility and simulates peak loads from distributed geographies, thereby reducing investment overhead in load-testing hardware setup and maintenance.
Silk Performer provides identification of client-side web page components which can be performance bottlenecks such as image sizes not optimized for performance, client-side resources being called serially wherein an asynchronous implementation may provide web page performance improvements.
- Silk Performer provides webpage performance breakdown which can show performance bottlenecks of webpage component, client-side network level.
- Silk Performer provides integration facilities with APM tools AppDynamics and DynaTrace, to resolve performance issues in code such as memory leaks, loitering objects etc.
- Silk Performer allows creation of custom load test reporting templates to suit business processes and requirements.
- Silk Performer Performance trend dashboard shows performance changes in the application for frequent build cycles and is useful to identify performance issues early in the development cycle.
- By adding content verifications in test scripts, it can help identify content errors under load.
- Silk Performer’s baseline testing approach allows to set acceptable response time SLA’s and subsequently aid, in flagging, transactions whose response time exceeds acceptable response-time.
- Silk Performer provides load injector health indicators (CPU, Memory, Responsiveness).
Best suited for enterprise-level performance testing services
Silk Performer is a performance testing and load testing tool that can be considered for fitment in multiple scenarios, as it supports a rich set of industry standard protocols. For e.g. consider the following scenario where checking performance with available software testing tools in the market could be really difficult.
Story/Alert message feeds sent in binary format via a TCP/IP connection with TIBCO enterprise messaging services as Middleware, to a third party NML server which converts these Story/Alert messages to NEWSML format & then forwards this message to BEA Weblogic server cluster, which processes this message and sends it to CMS and issues an output TIBCO broadcast message, to signal that the Story/Alert is successfully sent. These output TIBCO broadcast messages are sent via UDP protocol over TIBCO Enterprise messaging layer. Silkperformer does not support generic recording and playback of UDP based traffic. This limitation was addressed by developing Silk Performer load test scripts in conjunction with a COM DLL interface which follows event driven architecture, to wait for Tib messages and pulse event when .output message is received.
The objective of performance testing is to Measure the Performance improvements incorporated for NMS and BEA application servers by capturing processing times of each of these layers in above architecture.
(Note: NewsML is a messaging standard in xml format, that is designed to provide a media-independent, structural framework for multi-media news. TIBCO is a set of middleware products)
With Silk Performer’s enhanced TCP/IP support we can record protocols at the TCP level and customize the resulting scripts using WebTcpip functions. In Silk Performer we can create Listener which wait’s for a specific TIBCO message to arrive. The arrival of the TIBCO message is signalled by a Windows Event, pulsed by the StoryListener user.
Silk Performer’s TCP/IP TrueLog provides visual front-end diagnostics from the end-user perspective. TrueLog visually recreates the data that users provide and receive during full scale load tests which enables us to visually analyze the behavior of an application as errors occur. TrueLog Script Customization helps with a number of activities, such as session correlation. TrueLog automatically detects and customizes session-dependent information that is statically included in test scripts.
Below Silk performer sample code shows:
1.Creation of two user groups – Story_Sender and Story_Listener.
- Story_Sender sends a Story/Alert request to NML server, that should be followed by a TIBCO message coming in. Story_Sender starts a timer and is set to wait state, waiting for a specific Window’s event’s state to be set to “signalled”.Once the event is set to signalled, timer is stopped.
- Story_Listener is responsible for listening continuously to incoming TIBCO messages. After receiving a new TIBCO message, its message body(containing xml data) is parsed, and a corresponding windows event is signalled. Story_Listener is integrated via COM interface “ISilkPerformerUser” which enables Silkperformer to wait for Tib message’s and pulse event when .output message is received.
sEvent:= CreateEvent(sEventName);
//Open tcp/ip connection to myServer using port 23
WebTcpipConnect(hWeb,myServer,23);
MeasureStart(Timer1);
MeasureStart(“Timer1 : NML Process Story”);
// Send story message to NML
WebTcpipSendBin(hWeb,sMessage);
WebTcpipShutdown(hWeb);
// The Story_Listener User captures and parses resulting story message to Web Logic. It then pulses “sEvent”
// if successful.
nSuccess:=WaitForSingleObject(sEvent, 20000);
if nSuccess=WAIT_OBJECT_0 then
MeasureStop(“Timer1 : NML Process Story”);
MeasureStart(“Timer2 : WebLogic Processing Time”);
MeasureGet(“Timer1 : NML Process Story”, MEASURE_TIMER_RESPONSETIME, MEASURE_KIND_LAST, fValue);
Print( “Timer1 : NML Process Story took “+ string(fValue)+” seconds”);
// Initialise hEvent to expected .OUTPUT headline
sEventName := “TibMsg:” + sHeadLine;
hEvent := CreateEvent(sEventName);
end;
// Listening for “.OUTPUT” with user TibOutputLstnr. It pulses “hEvent” if successful.
bSuccess:=fWait_Tib(Timer2,sEventName, 40,hEvent);
if (bSuccess) then
MeasureStop(“Timer2 : WebLogic Processing Time”);
MeasureGet(Timer2, MEASURE_TIMER_RESPONSETIME, MEASURE_KIND_LAST, fValue);
Print(” Transaction execution took “+ string(fValue)+” seconds”);
elseif not (bSuccess) then return 0
end;
// fWait_Tib: Wait for a specific TIBCO message to arrive. The arrival of the TIBCO message is signalled by a Windows Event, pulsed by the StoryListener user.
//
// Arguments:
// sTimer: Name of the timer for the time measurement
// sEventName: Name of the Windows event to wait for
// fBound1: Service level (in seconds) for “Green” condition
// fBound2: Service level (in seconds) for “Yellow” condition;
// nTimeout: After waiting for nTimeout seconds, we give up and
// raise an appropriate error message
// Return value:
// True, if the message was received successfully
// False, in case of time out
var
sMsg : string(2000);
sTimestamp: string(100);
begin
if hEvent = 0 then
// Our naming scheme for Windows Events reflecting Tib messages start with “TibMsg:”
sEventName := “TibMsg:” + sEventName;
// Get a handle to a windows event
hEvent := CreateEvent(sEventName);
end;
// Wait for this windows event to be signalled, which will happen when
// the TibListener user receives a Tib messages matching this event
if WaitForSingleObject (hEvent, nTimeout * 2000) = WAIT_OBJECT_0 then
MeasureStop(sTimer);
sMsg := “Received event!”;
fWait_Tib := true;
else
sMsg := “Waiting for event ‘” + sEventName + “‘ timed out after “ + String(nTimeout) + ” seconds”;
RepMessage(“Waiting for event (“ + sEventName + “) timed out after “ + String(nTimeout) + ” seconds”, SEVERITY_ERROR);
fWait_Tib := false;
End;
CloseHandle(hEvent);
end fWait_Tib;
We ran a series of load tests and identified transaction’s queuing up on NML server due to synchronous call’s. After changing to a asynchronous implementation, and rerunning the load tests we were able to achieve peak hour load volumes for Stories and Alerts and were able to get Performance measurements of NML and BEA servers.
SilkPerformer’s inbuilt datastore MSDE was used to archive load test results from multiple test runs. With this data store, we could do a comparison of each test run against baseline run, and build a performance trend across multiple test runs for planned build cycles.
SilkPerformer’s custom reporting templates were useful in preparing test reports providing breakup of response timer’s for NML and BEA servers, and showing 90th and 95th percentile response time achievements of each transaction. This test reports could easily be migrated to MS Excel, MS Word, and SilkPerformer allows for publishing html version of performance test reports on online dashboards.
Verdict
After using the silk performer in many quality assurance scenarios, we found that it is flexible enough to be used in various scenarios to conduct performance testing, stress testing and load testing.
Author
