in reply to AJAX to reduce server load

JavaScript (and consequently AJAX) is a tool that can either be used to enhance a website, or abused to crud it up. As Perl culture, I think it we have a history of being open to all the tools at our disposal. Those dismissing AJAX out of hand because it's a 'fad' or requires JavaScript IMO are short sighted.

As to whether pm could use a little AJAX, I have no opinion, but the areas you suggested for enhancement don't strike me as providing any solid benefit. Server load is made up of more than just data retrieval and page creation. There's also session management and data verification which must occur regardless of how many bytes are returned.

Voting for example, still needs to verify the user session, and validate the node being voted on and retrieve the new vote count. This could add up to nearly the equivalent server load of the existing method or rendering the entire site view. Then you'd have to make additional AJAX calls to update all the other bits that come with the entire site view (cb, messages, xp). So now you've split one request, with one overhead, into several requests, each adding their own overhead. Now factor in that you can vote for several nodes in a single request without AJAX, but you have to make a new request for each vote with AJAX and you've multiplied the server load many times over yet again.

The most obvious reason to use AJAX is to enhance the user experience with a seamless 'non-refreshing' website and I think this should be the fundamental point. Arguing for AJAX based on sever load is a red herring IMO.

Replies are listed 'Best First'.
Re^2: AJAX to reduce server load
by bellaire (Hermit) on Mar 20, 2009 at 14:51 UTC
    I can understand that authorization takes time, however I don't think you've really given the ideas I put forth a fair shake. Particularly when you say:
    Then you'd have to make additional AJAX calls to update all the other bits that come with the entire site view (cb, messages, xp). So now you've split one request, with one overhead, into several requests, each adding their own overhead. Now factor in that you can vote for several nodes in a single request without AJAX, but you have to make a new request for each vote with AJAX and you've multiplied the server load many times over yet again.
    With respect, there is no reason you'd "have" to do things that way. That would be a very poor implementation. Obviously if you are going to send several AJAX requests for something that currently takes one request, you face diminishing returns. However, in my write-up, I specifically said that the voting AJAX could work just like the current interface, overriding the "Vote" button itself. This means that we have merely replaced a full page load (on submitting the vote) with a single AJAX request (on hitting the "vote" button).

    The entire point of the post was to identify situations which currently require a full page load and replacing those common activities with a simplified (single) AJAX request instead. This would not require increasing the number of trips to the server, but merely doing some of those trips via AJAX rather than reloading the page.

    I can accept that such a replacement would provide little benefit if the work done for an AJAX request is almost the same as it is for a page load. However whether that is indeed the case is a question for the pmdevs.

      Sorry, I mis-understood your vote example.

      But on the same train, if you're proposing (for example) that voting would work the same, without the full page load, then you've added nothing to the user experience, and 'maybe' only reduced the sever load a wee bit. I say a wee bit, because voting probably counts for a very small fraction of the site traffic. I'm sure the load is the result of casual browsers, not hard core voters (numbers anyone?). With AJAX voting as you've suggested, there's still the question of cb, xp vote counts and 'new' replies to the node you're currently viewing. These are updated with the full site request. The AJAX voting would have to either request and return this information as well (making it nearly as intensive request as a full page) or resort to additional requests to update the information (again increasing load). IMO your vote scenario is at least as load intensive if not more than the full site request.

      Of course, if you're talking about voting in the voting booth (not on nodes), then I'm trying to compare apples and oranges ;) I think the voting booth would be an excellent candidate for mixing AJAX to reduce server load. I also think using AJAX to update individual node votes (as I originally thought you intended) would also be a positive user experience, with a nasty load price.

      I think the cb could really benefit from AJAX. I'm not a big cb user, but I like to keep my eye on it while I'm reading nodes. I've always found it 'dis-jointed' to see the conversation skip along with each new page request and a real time flow of comments would be sweet. But doing so would replace the occasional page refresh with a constant nattering of AJAX 'pings' that surely will load the server even more. On the other hand, cb doesn't require any authentication to 'view' it, so overhead could be reduced.

      But I stand by my point that AJAX if used should be for the benefit of the user experience, and arguing that it reduces (or increases) server load is misdirection IMO.

        AJAX would be ideal for smaller partial page updates because a PM page can take upto 10 seconds to load (sometimes even more and my internet connection is fast). Thus for example voting/cb implemented with AJAX would definitely improve the browsing experience. Whether it would reduce the server load is debatable.

        --
        seek $her, $from, $everywhere if exists $true{love};
        if you're proposing (for example) that voting would work the same, without the full page load, then you've added nothing to the user experience

        I disagree strongly. Inline voting -- click and it's sent -- would improve the UI a great deal. No scrolling for the "vote!" button. No forgetting to submit some votes after reading a long thread. No 15 second page reload with a freshly broken URI -- /? -- from the POST.

Re^2: AJAX to reduce server load
by Anonymous Monk on Mar 23, 2009 at 12:41 UTC
    Voting for example, still needs to verify the user session, and validate the node being voted on and retrieve the new vote count. This could add up to nearly the equivalent server load of the existing method or rendering the entire site view. Then you'd have to make additional AJAX calls to update all the other bits that come with the entire site view (cb, messages, xp). So now you've split one request, with one overhead, into several requests, each adding their own overhead. Now factor in that you can vote for several nodes in a single request without AJAX, but you have to make a new request for each vote with AJAX and you've multiplied the server load many times over yet again.
    you don't know that of which you speak. doing a vote update does not require the cb to update. updating the cb doesn't require the votes to update. think man, THINK.