in reply to Why so slow from CGI, but not command line?

The solution is.....

Window NT doing strange things! When I wrote the script originally I ran it at home, however at work where I started to test it this morning, we have a Filewall and MS Proxy...

Even though the MS winsock proxy is supposed to deal with things transparently, it clearly doesn't work for processes running under CGI, probably a user/permission problem. Anyway when I run it under CGI Matt's LibXML waits around trying to access the external DTD, which it can't, so it gives up eventually - hence the minutes of waiting. If you remove the DTD then it runs just as fast as it does on the command line.

I now have to remove the DTD from the input XML files or make Matt's LibXML parser ignore the DTD (which is what I thought $xml_parser->load_ext_dtd(0); did), but I was wrong.

Many thanks to kappa, though it was the wrong suggestion, it did made me think external, and hence track down the answer!

I should have know that if it runs okay from the command line, but not CGI it almost certainly is a permissions problem....!

As ever thanks in advance......!

Replies are listed 'Best First'.
Re: Re: Why so slow from CGI, but not command line?
by Fletch (Bishop) on Apr 22, 2002 at 13:25 UTC

    As a handy debugging tip, any time you have code that's doing something `networky' (name resolution, creating a TCP connection) that mysteriously hangs for ~1-2 minutes it's often fruitful to use strace (well, not on NT of course :) or a packet sniffer (tcpdump, ethereal) to watch what exactly your code is doing when you see it hang (i.e. "Hrrm, it's sent a packet to the name server and it's now stuck . . .").

Re: Re: Why so slow from CGI, but not command line?
by kappa (Chaplain) on Apr 22, 2002 at 13:21 UTC
    Heh, my first thought was about fetching DTD or something :) But you almost clearly state that you run Apache on the same machine! Ah, ok, I am glad you solved your problem!
    And Windows NT looks innocent in this case, doesn't it? :)))