Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • John C Scott 473 posts 1183 karma points
    Jan 07, 2011 @ 12:38
    John C Scott
    0

    30 second timeout

    Having a very strange error with XSLT search.

    Set a site up pretty much based on XSLT search on a development server and it works great.

    It's been copied to a live server and every time XSLT search is called it waits 30 seconds before displaying the results. On the dev server it's a very reasonable 2 seconds or less.

    Any other XSLT file on the site comes back immediately.

    I've checked everything I can think of on the live server (permissions, files are the same etc) and I can't see any reason why this would be the case.

    This is in umb 4.5.2 with xslt search 3.0 both dev & live server on win2k3 iis6.

    Any ideas why this might happen?

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Jan 08, 2011 @ 11:35
    Douglas Robar
    0

    Hi, John,

    XSLTsearch does nothing special, using either $currentPage or GetXmlAll() and then parsing through the content nodes returned. 

     

    You might enable debugging in the web.config and append ?umbDebugShowTrace=true to the querystring of a search. Then you can see what is taking so long in the trace.

    Also, set the XSLTsearch macro parameter to display the statistics. This will show how many pages were searched and how quickly. The timing is not 100% reliable but if you find it is only a few seconds yet the page takes many seconds to display it might be a bandwidth issue -- too much data being returned to the browser of a slower connection than your dev server has, for instance.

     

    Out of curiosity, how many content nodes are you searching through, and how many hits do you return at a time? 

    Another thought... if you view the search page without actually searching anything (so you get the search form but not performing a search), is that fast or slow? If fast then it is probably something in the searching itself. If slow, then perhaps it is an issue with the larger macro itself. 

     

    cheers,
    doug.

  • John C Scott 473 posts 1183 karma points
    Jan 08, 2011 @ 22:05
    John C Scott
    0

    Thanks Doug.

    It's very odd this one. In the end we fixed it by setting up a new server and copying it there. For some reason it was something about that server.

    On the new server everything works perfectly.

    There's only 185 nodes being searched so it's tiny really. An empty search takes the same amount of time. It's such a shame as initially they were incredibly impressde that I built the entire site (sadly behind a firewall) it's a staff directory site in an afternoon. But then there's now been 2 weeks of this server issue. But I think they entirely accept it's their server and their problem. At least I hope they do.

    Very pleased with my most recent site for them - it's a major upgrade with some quite clever stuff - and it was completed in 3 days entirely in xslt and only using the browser and notepad++ (and a pencil) :D

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Jan 10, 2011 @ 10:47
    Douglas Robar
    0

    Glad you have a happy client and the new server is working properly.

    Would still love to know the cause of the problem though. If calling up the search page but not searching for anything is dramatically slow then it is a very basic issue since almost no logic is being performed.

    All the dictionary keys are being referenced though so if you don't have them in your installation that might slow things down (though hard to imagine it would be anywhere near as slow as you indicated). Does the 'faulty' server have the XSLTsearch dictionary keys?

    Another question, if you make a simple template with a <form runat="server"> tag, does it take ages to render? That's really all that XSLTsearch is going to generate when you aren't searching for a term.

     

    ...inquiring minds want to know :)

    cheers,
    doug.

Please Sign in or register to post replies

Write your reply to:

Draft