Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3
  1. #1
    Regular Coder
    Join Date
    Jul 2002
    Posts
    165
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Caching an entire site into arrays

    Erm, didn't want to do that however i managed to, just deleted my msg - here we go again

    I have a class within which exists an array of tables, fields and values.

    Each visit to a page, I used to load open db, load the pages data, print it, then close db... bored of this now, Now I'm looking to keep every part of a site in an object which is passed around using the session, hopefully meaning any one thing is only loaded once unless 'dirty',

    If I had 5000 users at any one time visting a site, and each user loads 1000 records of data for args sake, each 2,000kb in size, so 200,000k, what would the speed/memory implications of this be...? is it worth it? am i being silly? testng works fine, but a bit difficult to simulate 5k users even using the web testing rubish that comes with visual studio and others, found them to be useless in my dissertation, too inconsistent and inaccurate.

    Any ideas and comments however zany (as long as relevant) are welcome

    Thx

  • #2
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,073
    Thanks
    11
    Thanked 98 Times in 96 Posts
    caching a whole site in a session for each and every user is I think ... errr 'daft' is a nice word

    though that depends on exactly what you are keeping .. if you mean storing HTML in your session then the above definately applies.


    how much of your site can be really cached ? , eg stored as html pages , even in a highly dynamic site its still possible to cache an awful lot of content.

    eg once someone calls a dynamic page , you keep a static copy of that page (or as static as possible) and only rebuild it when some data relevant to its construction changes , eg in a forum you may cache a thread up until someone makes a new post , then you cache the newly rebuilt page , not a good example but perhaps along the right tracks ?
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #3
    Regular Coder
    Join Date
    Jul 2002
    Posts
    165
    Thanks
    0
    Thanked 0 Times in 0 Posts

    caching methods

    Hmmm, well, at the moment, a page is built using a relational db and recs as objects, so one template is made up from n layout objects, and each layout object is made up from n content objects.

    We were trying to work out the best way of caching pages, ideally we would like to cache the framework for each page which will store layout type html, e.g.

    Code:
    <center>
    <table cellspacing="0" cellpadding="0" style="width: 700; height: 500;">
    <tr>
    	<td colspan="2">
    		<div id="divA" style="width: 700; height: 100; border: thin dashed blue;">
    		
    		</div>
    	</td>
    </tr>
    <tr>
    	<td>
    		<div id="divB" style="width: 200; height: 400; border: thin dashed blue;">
    		
    		</div>
    	</td>
    	<td>
    		<div id="divC" style="width: 500; height: 400; border: thin dashed blue;">
    		
    		</div>
    	</td>
    </tr>
    </table>
    </center>
    Then the only time the framework will change is if timestamp is different... is this feasible?

    There may be many templates, and many structures inside with which to fill later in the same style, but no more than 10 (estimate) in total for each page.

    The content can then be read/reread each page time but the framework to fill will aready exist...


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •