You can perform the following steps to troubleshoot the issue.

1. Try searching through RTV. If you are able to search using RTV, then the Search Server is operational.
2. You may want to examine the state of individual indexes in the Search Server. To do so, you must configure RTV to use the same Search Server.
   1. If you are able to successfully connect to the same Search Server, the list of available indexes is displayed beneath the server node in the Search Setup window.
   2. To review a summary of the indexes for the Search Server, select the server node and click Summary.
   3. In the Summary page that is generated in your browser, you can review the status of each index that is managed by the search server. Review the From and To timestamps and the values for Index, Size, and Session Indexes. If these fields have meaningful values, you should be able to search for session data between the From and To dates.
3. If Search Server appears to be operating properly through RTV, the issue may be with the Data Service. The Portal acquires its set of available indexes from the Data Service. Complete the following steps to verify that the Data Service is operational.
   1. In the Portal, navigate Portal Management.
   2. Click the Manage Servers link.
   3. Select the Data Service server.
      • If the Data Service server does not exist in the list of servers, click the Display Inactive check box. If the server now appears, you must activate it.
      • If the Data Service server still fails to appear, you must create an entry for it.
   4. When the Data Service server is selected, in the toolbar above the list of servers, click the Ping tool in the toolbar. Version and request information should be displayed in the Data Service Server Status panel below the list of servers.
4. If the Data Service server does not respond, try restarting the Data Service.
   Note: While the Data Service is restarting, the Portal is unable to connect to other Search Servers and the Tealeaf databases. Typically, restart takes only a few seconds.
   1. In the Portal, navigate to TMS.
   2. In TMS, select the WorldView tab.
   3. From the View drop-down, select Servers.
   4. Click the Data Service node.
   5. In the Server Actions, click Restart.
5. If the restart does not resolve the issue, the problem may be related to any of the following:
   1. Inadequate permissions
   2. Special configuration for the Portal in IIS or ASP.NET required to connect to Search Server must also be applied to the Data Service.
   3. Use of raw IP addresses in the server addresses of the Portal Management page. Use server names instead.
   4. Proxy server between the client browser and the Portal. Disable the proxy if possible or configure it to manually connect to the Search Server.

The temp path must be a fully qualified path. If the path is not fully qualified, the path is treated as a relative path, and the resulting behavior depends on the current drive directory:

• Search server might refuse to start, and an event log error might indicate a problem with the temp path.
• Search server might return Status Code 400 errors on commands that use the temp drive, such as searching or retrieving the list of indexes.

The fix is to use full path names for values in Search Server configuration.

The all text search of the response includes every word that is considered "meaningful".

• To reduce disk space requirements for indexes, noise words, single letters, HTML tags, and JavaScript™ code are excluded from indexing.

In a request, specific items are included by default.

1. To see approximately what is indexed and thus searchable in a response, open the CX RealiTea Viewer and examine the response view of a typical page.
   1. Right-click the response view
   2. Select the Indexed view or use the drop-down menu on the right side of the RSP button on the toolbar.
2. This view indicates the words for which you can search in the response to find a specific page.

Tealeaf uses two different search engines:

• dtSearch Indexer is the more powerful one and is invoked when searching completed sessions through RTV or the Portal.
• string comparer is a simple string comparison search facility, which is invoked when you search for active sessions.

The word NOT is not indexed, which means it cannot be searched for. Likewise, hyphens and other punctuation characters are not indexed, as they are considered word separators.

You want to search for the URL slp-system-not-available.html. Entering this string results in few if any matches. From Portal Search, search instead for "slp system available", including the double quotation marks.

The word html was left off at the end of the search to widen the net on the first search. If you find the three-word search is returning incorrect hits, then you can add the fourth word html to the phrase to narrow the results set.

To avoid this situation, the Indexer replaces any special punctuation characters in the name (left of the = sign) with underscores (_). For example, to search for ~cc_num, enter the field name as _cc_num.

Suppose the web pages for a business process consist of the add an item, start checkout, and complete checkout events. Assume that the website allows for a long application timeout and that the Tealeaf STC session timeout is configured to be less than the application timeout.

This discrepancy is often necessary, as the Short-Term Canister usage directly affects RAM consumption in the Tealeaf server.

A visitor to the site could add an item, start checkout, go have dinner, and return to finish the checkout an hour later. This behavior results in one session fragment containing the first two events, and a second, later session fragment containing the final complete checkout event.

Tealeaf search looks for session fragments. A search for events 1 and 2 and not event 3 would find session fragment 1 and not fragment 2. When replaying session fragment 1, the user can select Find all fragments of this session, which replays a single logical session consisting of the contents of both session fragments. The merged session has all three events, which are not what the original search requested.

For most sites, it is difficult to completely avoid fragmentation. To reduce fragmentation, you can increase the duration of the STC timeout, which may impact STC RAM consumption. Over-consumption of the STC RAM leads to spooling, which may cause fragmentation. Spooling should be avoided wherever possible. You can experiment with gradually increasing the STC timeout until fragmentation is reduced to a tolerable level without increasing spooling.

Another approach is to find a representative sample of the fragmented sessions, analyze them for the time duration that contains all events of interest, and set the STC timeout such that 95% or other desired percentage of the user sessions are not fragmented for the events of interest.

This solution explains how to determine if your disks are creating a performance bottleneck:

1. Run the Windows™ PerfMon utility.
2. If the Average Disk Queue Length counter is not already displayed, right-click the right pane and select Add counters.
3. In the Performance Object drop-down, select Physical Disk.
4. In the rightmost set of radio buttons, select All instances.
5. In the left pair of radio buttons, select Select counters from list.
6. Select the following three counters from the list box:
   • Avg Disk Queue Length
   • Avg Disk Read Queue Length
   • Avg Disk Write Queue Length
7. Click Add.
8. Look at the results in the perfmon right pane. Focus on the disks that house the CANISTER, dbs directory, and the Indexes directory.
   • Average queue lengths should be less than 1.
   • Queue lengths of 4 or greater mean the disk is I/O bound.

Average queue lengths of 4 or more are a strong indication that the system's disk drives need repartitioning along the guidelines of Solution 65.

If your system is configured according to Solution 65 standards, does not use RAID, and has high average queue lengths, the solution is to move to a faster disk subsystem or add additional Tealeaf servers. The current system does not have the disk I/O bandwidth to handle the data processing load that is presented to it.

For example, you might receive the following entries in the application event log:

(18:49 Search Server) - TeaLeaf Search Server Ver: 6.2.0.6250 -
   RestartOnDtSearchHang
(18:01 Search Server) - TeaLeaf Search Server Ver: 6.2.0.6250 -
   RestartOnDtSearchHang
(16:21 Search Server) - TeaLeaf Search Server Ver: 6.2.0.6250 -
   RestartOnDtSearchHang

Search Server is unable to complete the requested search due to disk performance issues or insufficient time to complete the search.

1. Run the Windows PerfMon utility.
   1. Check the average disk queue length of the disk where the Tealeaf Indexes directory resides. If this value is typically larger than 1, the disk cannot keep up with I/O requests.
   2. Close PerfMon.exe.
2. Use Microsoft's SQLIO benchmark utility to assess the disk speed.

   If the disk's throughput is less than 50 megabytes/sec, it is not fast enough for the processing volume that is required by the Tealeaf server. Consult with your IT department for ways to improve the disk I/O performance.

3. In the Portal, navigate to TMS.
4. From the View drop-down, select Servers.
5. Click the Search Server node.
6. Click Search Server configuration.
7. Click View/Edit (raw).
8. In the window, click the Default group.
9. Change the value for WatchDogIndexSearchSeconds to double or quadruple the current value.

   If necessary, you can set the value to 0 to disable this feature entirely.

10. Click Save.
11. Assign and push the configuration.
12. To apply the new value, restart Search Server.