9

I wrote a java app to communicate with a web application using XML. After deployment, I found out it takes too long to parse the XML generated by the web application.

For example, it takes about 2 minutes to login; the login information is included in the url. The web application does its processing and responds to the Java app whether the login was successful using XML returned.

I used the standard java DOM parsing.

Is there a way I can optimize this process so that activities can be faster?

Nishant
  • 54,584
  • 13
  • 112
  • 127
yomexzo
  • 665
  • 1
  • 6
  • 22
  • 10
    for a start, please choose a valid question title. – Bozho Jun 01 '11 at 16:52
  • 8
    In Soviet Russia, question asks you! – whirlwin Jun 01 '11 at 16:53
  • 2
    The key here is you need to profile your code. There are bottlenecks in certain parts of the code. Once you identify those you are already likely almost at the point where you can do optimisations. The trick is knowing where to optimise. – Mike Kwan Jun 01 '11 at 16:56
  • @Bozho updated the post. @yomexzo paste the code. Most likely, your webapp response time is too high or you have some sort of network latency. Use capital I, and try to avoid unnecessary use of ellipses (...). – Nishant Jun 01 '11 at 17:00
  • do you mean you dont understand my question? – yomexzo Jun 01 '11 at 17:01
  • DocumentBuilder db = dbf.newDocumentBuilder(); Document dom = db.parse(uri+"login.cfm?username="+user+"&password="+pass); I figured it's the parse method that takes all the time... – yomexzo Jun 01 '11 at 17:16
  • I know you would never engage in guesswork :) But if you "figure" something takes the time, that's quite far from *knowing* what takes the time. – Mike Dunlavey Jun 02 '11 at 17:18

4 Answers4

33

I've runned into the same issue and managed to speed up parser by switching off all validation that DocumentBuilder will do by default:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setNamespaceAware(false);
factory.setValidating(false);
factory.setFeature("http://xml.org/sax/features/namespaces", false);
factory.setFeature("http://xml.org/sax/features/validation", false);
factory.setFeature("http://apache.org/xml/features/nonvalidating/load-dtd-grammar", false);
factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

// then take a builder via `factory.newDocumentBuilder()` and parse doc with that builder
om-nom-nom
  • 62,329
  • 13
  • 183
  • 228
3

The parse method takes all the time because it's waiting on the input from the other application. You need to separate the two so you can see what's going on. Read the XML from the other application into a ByteArrayOutputStream, then when that's done, copy the output stream to an input stream (you can use commons-io for that) and feed that to the parser. Then see what is really taking all the time.

One thing that you could optimize is your login process. You could use an LDAP server to do authentication against, LDAP is optimized for reads and you can access it with JNDI.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
  • just figured it takes about 5seconds to perform a transaction with the server.... about 5 of such transactions occur making the application slow to launch.... This time is too much.... What do I do????? i have tried using SwingUtilities.invokeLater() and tried using thread on subsequent transactions after the login transaction so that the application JFrame at least displays.... unfortunately, the JFrame hangs – yomexzo Jun 02 '11 at 14:10
  • 3
    @yomexzo, did you know the more question marks one puts, the better and faster answer they get! – bestsss Jun 02 '11 at 21:10
3

Using a standard XML parser a short message should be parsed in about one milli-second. Using a custom parser you can cut this to about 20 micro-seconds. Any time longer than this is not in the XML parsing

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • just figured it takes about 5seconds to perform a transaction with the server.... about 5 of such transactions occur making the application slow to launch.... This time is too much.... What do I do????? i have tried using SwingUtilities.invokeLater() and tried using thread on subsequent transactions after the login transaction so that the application JFrame at least displays.... unfortunately, the JFrame hangs – yomexzo Jun 02 '11 at 14:10
  • invokeLater still uses the GUI thread so it will still lock up the GUI. I suggest you use another thread to trigger the background task. The real problem appears to be you server being too slow. 100 ms should be more long enough to do a simple task. You need to investigate what your server is doing and see if it can be fixed. – Peter Lawrey Jun 02 '11 at 14:18
  • You should be able to get a thread dump and see what your GUI thread is waiting on. – Peter Lawrey Jun 02 '11 at 14:39
0

What @Nathan said, plus I suggest doing some random pausing while it's taking so much time. I've run into this in the past, and discovered it wasn't the parsing that was taking the time, but the creation and manipulation of data structure as it parsed. You may see something different, but chances are it's a surprise.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • just figured it takes about 5seconds to perform a transaction with the server.... about 5 of such transactions occur making the application slow to launch.... This time is too much.... What do I do????? i have tried using SwingUtilities.invokeLater() and tried using thread on subsequent transactions after the login transaction so that the application JFrame at least displays.... unfortunately, the JFrame hangs – yomexzo Jun 02 '11 at 14:09
  • @yomexzo: When you take stackshots, what do you see? What % of samples show waiting for sending/receiving to complete? What % show manipulating data structure (creating, destroying, initializing, copying, notifying, registering)? Are any of them doing something else you didn't think of - like logging maybe? They will tell you what's actually costing time that you might not have thought of. Then it becomes very clear what your options are and how much they can save you. – Mike Dunlavey Jun 02 '11 at 17:14