Performance Analysis CoreTegral 18/8/2011

Transcription

1 Performance Analysis CoreTegral 18/8/2011 This document describes a real world plus test of CoreTegral to determine the performance of a typical CoreTegral automation solution when hit with large amounts of data. This test was deliberately not optimised so that the figures are for a very standard solution, using all levels of data translation (e.g. SECS1, SECS2, SECS2->XML, XML->VFEI). In addition to this all data is logged in the SQL Server data cache before being passed on to the higher level (Data Collector, Data Provider) components and to the standard template workflow provided with CoreTegral. Although the workflow is not manipulating the data, every data event is delivered to, and processed by, several parallel logic threads in the workflow to determine if they are relevant to the control flow (e.g. Material Arrival, Run started etc.). Finally, the data is subscribed to a remote data client, passing in object form over a TCP remoting channel in the same way as it might pass over a 3 rd party bus or a web service to an InterfaceA, or other client. The data is displayed on a remote UI to confirm its availability. Detail The test is based around the tool modelled in the standard CoreTegral template solution. However, the number of events is increased so that a loop of 100 WaferStart, WaferData, WaferComplete S6F11 event sequences are sent by a tool simulator in rapid succession over an HSMS connection during the Run. In addition to this, the WaferData event is expanded to include 25 complex data variables each having 4 sub variables, giving a total of 100 data items in each event to be parsed out, normalised with context into the database and then provided as required to the EDA client application whilst monitoring and controlling the Run. To provide the simulated data as quickly as possible, the general SECS tester application is replaced with a coded ToolSimulator component which runs as a separate solution. The simulator solution is shown below:

2 The custom coded simulator is a simple component that reacts to the incoming messages from the automation solution, and responds appropriately. The key code section below shows how it reacts to the S2F41 START command from the automation. The heart of the test is the loop of 100 wafers, each with 100 data points of mixed type. There are 3 S6F11 events for each wafer and all are sent as rapidly as possible over the HSMS connection.

3

4 The standard template solution is running as the automation, as shown below:

5 When a run is put through the solution, the data can be seen at the remote client. The client is subscribed to wafer data, and showing specifically the X_COORD sub item. This loops from 100 to 125 for each wafer as shown by the (j + 100) value in the above code inserted into the data message within the j loop.

6 Time-stamped log files are kept for the run in order to get a feel for the performance. The full logs are attached, but the following summary excerpts show the relevant detail: Example from Simulator Log: Embedded Log Files: andrewsimulator_testdc_4.log TESTDC_andrew_1.log

7 Example from Automation Solution Log:

8 Conclusion It should be noted that the timestamps on the logfiles are not 100% accurate, since the act of writing the files themselves has an effect. However, they are considered accurate enough for these purposes since any errors would tend to increase the figures rather than decrease them. This test showed that the default standard solution without optimisation was able to handle significant quantities of events (300) in rapid succession and containing significant data (100 data items 100 of the events). No data was lost or events missed, and all data was placed with context into the database and delivered to a remote UI client via remoting URL. The typical time taken to process an event containing the data was approximately 55mS, and this included: Handling the low level HSMS protocol Parsing message content to SECS2 Parsing SECS2 into XML representation for easier use by integrators and developers Intelligent parsing of the SECS into VFEI, recognising the content and adding appropriate item names to all SECS values Adding context to the data (i.e. associating the wafer data with the correct wafer; hence lot, carrier and run in the database) Writing the data to the database Passing events to the running workflow (workflow examines them only to see if a significant event has occurred - e.g. equipment state change) Fulfilling client data plans that include a request for the data (in this case one data plan from a remote UI client) It should be noted from the logs that full use of threading is made for performance e.g. the S6F12 reply message is sent back to the equipment at the same time as data is being written to the database and passed on to the workflows and clients. The test was carried out on a standard demonstration laptop (approx. $400 a year ago), with a standard SATA drive. System information shown below:

9 The laptop is running a full SQL Server 2008 R2 installation, and has Visual Studio 2010 installed and is also running an RMS system.