Often the diagnosis of slow performance comes from a query load played against the front-end application. The front-end application, or the configuration of its application server, may be the reason for the poor performance.
Alternatively, the network may be the problem, although this is less likely.
To identify whether the network is a performance issue:
Compare Eneperf performance on the local host and a remote host. First, run Eneperf against the Dgraph on the Dgraph machine. Next, run the same Eneperf against the same Dgraph, but from the front-end machine (if possible), or somewhere on the other side of the network. If the difference is negligible, the network is not a problem. If Eneperf across the network is slow, you need to consider both the network itself and the application configuration.
Alternatively, you can run the Request Log Analyzer and compare the “Round-Trip Response Time” with the “Engine-Only Processing Time”. If “Round-Trip Response Time” is long but the “Engine-Only Processing Time” is short, this can indicate a network problem or a configuration of an application server for the front-end application.
Measure network performance using Netperf, a freely available tool that can be used to measure bandwidth. Alternatively, you can FTP some large files across the network link. If these tools show poor throughput across the network, this can indicate a network hardware problem such as a failing network interface card (NIC) or cable.
In addition, check Eneperf statistics, the Dgraph request logs, or the Dgraph Stats page to see how much data is being transmitted back from the Dgraph on an average request. Large average result page size can saturate the network.
If it seems as if your application is trying to move too much data, it is likely that you may need to change the configuration of your application. To determine if changes are needed, consider the following:
Is all of the data actually being used by the application? In other words, does the MDEX Engine return record fields that are then ignored by the front-end application? This is an especially serious problem with large documents.
Is your application returning unnecessary fields with the Select feature? (This is described in “Controlling Record Values with the Select Feature” in the MDEX Engine Developer's Guide.)
Is your application returning navigation pages that are too large? (Navigation pages are result list pages, as opposed to record detail pages.) If the application returns a lot of detailed information in the result list pages, consider reserving the details for a click-through and reducing the size of the result list pages your application returns on initial requests.
Is your application returning large numbers of records without using the bulk record API? (This is described in “Bulk Export of Records” in the MDEX Engine Developer's Guide.)
Is the network saturated? Upgrade to Gigabit Ethernet and identify the transmission speed being used. Ensure there is ample network bandwidth between the front-end application and the Dgraph. To identify Gigabit Ethernet transmission speeds, work with your network administrator.
What is the configuration of NIC cards? Ensure that NIC duplex settings match between the Dgraph host and the web application client host and that both are set to full duplex. A mismatch can cause latency issues.
Could large response sizes returned by the Dgraph be saturating the network? Use the Request Log Analyzer analysis to confirm large response s izes returned by the Dgraph, which can be caused by the query features you use. The way certain features are used can cause slow processing time and also saturate the network.
Do you have queries waiting in the Dgraph queue to be processed? Check "Threading/Queuing Information" summary in the Request Log Analyzer for the number of items experiencing queue issues and the number of HTTP Error request 408 timeouts. Review the Dgraph setting for the number of worker threads and consider increasing it, if it is set to 1. Queuing can also be caused by spikes in traffic.
Does the front-end application process the responses returned by the Dgraph quickly enough? Check CPU, memory, and disk I/O utilization on the front-end application server. Ensure the application server does not need to be tuned and that large responses are not being returned by the Dgraph.
Related links
This topic discusses how to debug connection errors with ENEQuery exceptions.
Problem - The application server does not seem to connect to the Guided Search server. The reference application has no difficulty connecting. A connection to the port works as confirmed by JUnit tests. A problem exists connecting to the server once all the reference application libraries are packaged into the EAR file that is run inside the WebSphere application server.
Solution - In general, the
HttpENEConection.query ENEQuery method is used to
issue a query against the Dgraph. In the
HttpENEConnection.query method in the Java version of
the Presentation API, any connections problems are raised as an
ENEQueryException. (There is an equivalent in .NET
version of the Presentation API).
To diagnose a connection problem from an application server to an Guided Search server, the following assumptions are made:
To troubleshoot the connection problem, do the following:
Verify from the application server machine that you can connect to the port on the Guided Search server. Using telnet on Windows or Unix can help you determine if you can successfully make a connection:
telnet <hostname> <dgraph port>
If you cannot establish a connection with telnet, check that the Dgraph process is running with the specified port. Check the Dgraph
stderrlog to confirm the Dgraph was able to successfully bind to the port and another process is not using the port. You can also verify the Guided Search server machine is listening on a socket with the specified port usingnetstat -a. Check that a valid network route exists from the application server to the Guided Search server. You can also useping. Also, usetracerton Windows,tracepathon Linux, ortracerouteon Solaris. If no valid network paths exist, check with your network administrator to eliminate possible problems with a firewall or routing configuration.If you can obtain a connection from telnet, verify that the application server can talk to the Guided Search server. Write a Java program with a
static void mainmethod to make a connection to the MDEX Engine on the Guided Search server. Make sure the Navigation JAR file is included in your classpath. If this program makes a connection successfully, the problem should only occur within the application server.
Write a utility JSP page that connects to the MDEX Engine on the Guided Search application server and place it on the application server to verify the connection. Alternatively, you can run the Reference Application on the application server.
If everything works correctly, to troubleshoot further check the application server configuration. For Websphere, do the following:
Assuming that you have WAS 6.1, go to → and check whether Java 2 security is enabled. If it is enabled, make sure your
was.policyfile is saved in the META-INF directory.
