• (disco)

    That reminds me of another software package that slows down when it tries to serve actual content…

  • (disco)

    Makes me think there is some buffer flushing problems.

    But buffers probably won't flush automatically within a time limit, will they?

  • (disco) in reply to Anonymous
    Anonymous:
    Makes me think there is some buffer flushing problems.

    But buffers probably won't flush automatically within a time limit, will they?

    Maybe they got clogged with slush.

  • (disco)

    If this was an international application, there was probably a duty on the bits..so the 30 seconds was pretty quick because it was the time required to apply for and get an exemption on the bits duty :wink:

    All of this is why CERN has a duty free tunnel between the Swiss and French parts of its facility.

  • (disco)

    The description of the 3CoH sounds a bit familiar to me. Does it's name sound something like "Statics By"? ;)

  • (disco)

    Ian was testing by pointing to the vendor's QA website and not the real one, so he naturally assumed this was the cause of the slowdown.

    TRWTF

  • (disco) in reply to dstopia

    Turns out it was actually slow because he was monitoring it from another site and running some bots

  • (disco) in reply to Jaloopa

    OI!

    .... yeah we did that but it wasn't on porpoise! i swear!

  • (disco) in reply to RaceProUK

    That's discoursting. Should I even ask what software package we're referring to?

  • (disco) in reply to powerlord
    powerlord:
    Should I even ask what software package we're referring to?

    That doesn't sound too civilized...

  • (disco) in reply to Jaloopa

    You're right.

    I hope me asking doesn't get Jeffed to a new topic.

  • (disco)

    So...http response code 309? What would that even do? As far as I can tell, that's an unassigned response code.

  • (disco)

    TRWTF is that he somehow got browsers to freeze while requesting a resource. Sounds like trying to use XMLHttpRequest synchronously...

  • (disco) in reply to NBeezy

    A synchronous Ajax query shouldn't hang the browser page, either. They probably used an asynchronous XMLHttpRequest and wrote something to the effect of while (!connection.ready) { } instead of writing actual asynchronous event handlers for it.

  • (disco) in reply to anotherusername

    I just ran two tests and it seems like both synchronous XHR and using a while loop to check the status will lock up chromes UI but not cause it to ask you to kill the page (although idk what rules chrome uses to determine a script is hanging the execution)

  • (disco)

    Reminds me of a fancy, enterprise-y system I worked on a long time ago. It used a Java back-end that could talk to a PHP "front-end" through SOAP. The problem was, requests would take a long, long time. A little bit of troubleshooting later, I discovered two things:

    1. The requests were well over a megabyte of XML for even the simplest of things, because they apparently included everything you could ever wish to know, in the most elaborate form possible, and:
    2. While PHP happily parses a meg of XML in about a dozen milliseconds, the much beefier back-end needed almost twenty seconds to produce it. Not for generating the data, assembling it, or anything like that mind you. Oh no. Transforming the data from a Java object into some XML by an external library was the culprit.

    I kid you not. By going down to an older version of that SOAP library, the responses somehow got a bit bigger, but ran twice as fast. Of course, cherry-picking a random library version just to have speedy responses is not something to make you sleep happily on a Job Well Done, but as it turns out the Java back-end was written by some Consultants who were handed the merry job of Fixing The Damn Thing. Never quite did find out whether they did, I left that company pretty soon after.

  • (disco) in reply to boldtbanan

    Likely they put 307 or 308, but it got anonymized to 309. Or really they just wanted to send an unassigned status code and they got passed the checks, which might only check the known ones and default: don't delay for unknown.

  • (disco) in reply to Nprz

    I wonder if they tried a 204. https://www.google.com/generate_204

  • (disco) in reply to FragFrog
    FragFrog:
    Transforming the data from a Java object into some XML by an external library was the culprit.

    TRWTF as there are actually good, fast libraries for that sort of thing. JAXB's been a thing for ages now.

Leave a comment on “The Third (Party) Circle of Hell”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article