in reply to Re^2: Read Only Perlmonks
in thread Read Only Perlmonks

As the server will have to dynamically render each page anyhow (barring any cache-ing issues -- and those will be the same for a read/write as for a read-only site), adding the few links which allow you to go to a page where you can enter your comments, would not really make a difference.

The speed (or perceived lack of it) has nothing to do with the fact that we can write comments.

If you never write a comment, you will not experience any delays in your comments being accepted, but the rendering of the pages will be as "fast" (not faster) as for anyone.

Now if there was a separate server that only serves pages to those who are not interested to make comments, there is a chance that it might be faster, but only due to the fact that that server would be less used and thus the load on the server --by definition-- will be less. But if you are adding another server anyhow, why not make it a full read/write site also? If you divide the load over more servers, you get better response in any case.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Replies are listed 'Best First'.
Re^4: Read Only Perlmonks
by almut (Canon) on Jan 07, 2010 at 12:16 UTC
    ... But if you are adding another server anyhow, why not make it a full read/write site also?

    A read-only mirror might be faster (than a read/write one), because synchronisation would need to be one-way only, so you wouldn't have to take care of nasty locking issues, etc.

    That said, I'm not sure it would generally be a good idea... for the same reasons already mentioned.

      You have to compare like with like: as the read-only site would not have the comment options, you can only compare the speed of the pages where there is no writing to be done. I still think that deleting the comment options would not make the site any faster, for the non-writeable parts that is.

      As the data for the whole site is kept in a database anyhow, synchronisation, one way or both ways, will be handled on the database-level. It should be transparent on the web-server level. And of course for the non-writeable pages, it is one-way by definition.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        Nice hand waving. There have been at least 3 read-only mirrors of PerlMonks. They were each significantly faster than PerlMonks and likely hosted on significantly less hardware.

        I don't believe any of them are still being maintained.

        Now, surely a large part of the speed / resource difference is related to none of the mirrors ever having taken a significant fraction of the traffic of PerlMonks.

        However, the mirrors were substantially simpler. I would expect their page generation to be at least an order of magnitude more efficient. A read-only mirror has little reason to allow you to log in and thus doesn't have to deal with authenticating each request, loading user settings, rendering nodelets, updating user stats, storing nodes in the form that users edit them while displaying them in a different form, etc.

        A read-only mirror really acts like a cache, just storing the nodes as they are to be displayed and just serving up nearly static content. Yes, that will always be tons more efficient. I suspect it is typically closer to two or three orders of magnitude more efficient.

        - tye        

        CountZero wrote:
        > As the data for the whole site is kept in a database anyhow, synchronisation, one way or both ways, will be handled on the database-level.

        Since this is Perlmonks, shouldn't we have a bevy of monks cutting and pasting the site by hand?