Welcome Guest, Not a member yet? Register   Sign In
Checking for non-logged in users before showing cached pages [Adv.]
#11

[eluser]BrianDHall[/eluser]
I suppose kurucu actually kind of brings up the point of the problem with 'premature optimization' - seeking to optimize something you don't know will actually be a problem. It requires a great deal of planning and consideration to implement, and ultimately for most sites will be a local optimization that only works on some pages.

Now if a site is largely static then this is fine, though I wonder if the site is largely static if there shouldn't actually be a system used to write files to an actual html file and just have a cron going through a determining ever so often if any files need updating due to newly added or changed content. Then pages that won't benefit from caching are excluded, or not manually included.

Again though, this might be a useful tool for optimization in theory, but if it is being implemented before its an issue you might be mending a bridge you will never actually cross.

I've yet to ever build an app that turned out exactly like I thought it would in the beginning, and even now I have static pages that could, in a single day, become something that will need to be dynamic.

For my money, if you want to really capitalize on caching enough to make it worthwhile you have a CI system that generates static real .html pages, you have an htaccess system that permits accessing a file directly if it exists (so the .html file doesn't get redirect if it really exists).

Hm, here's a thought thats more in line with the OP - what if you edited the index.php file to check for a cookie and then either served a cached page or static html page, or then proceeded with loading CI? Then the overhead is just a very small 1 page php script to check for the cookie.
#12

[eluser]Xeoncross[/eluser]
[quote author="BrianDHall" date="1253735683"]I suppose kurucu actually kind of brings up the point of the problem with 'premature optimization' - seeking to optimize something you don't know will actually be a problem.[/quote]

My sites have received millions of page views since their launch. I have sites running wordpress, drupal, and frameworks. So in my case optimization is a valid issue - one which I intend to fully use to my advantage.

Quote:For my money, if you want to really capitalize on caching enough to make it worthwhile you have a CI system that generates static real .html pages, you have an htaccess system that permits accessing a file directly if it exists (so the .html file doesn't get redirect if it really exists).

MoveableType took this approach and we see that it is causing performance problems for them. Imagine changing one sidebar link used on a site with 300 articles - you have to regenerate all those pages.

Quote:Hm, here's a thought thats more in line with the OP - what if you edited the index.php file to check for a cookie and then either served a cached page or static html page, or then proceeded with loading CI? Then the overhead is just a very small 1 page php script to check for the cookie.

Bingo. I have actually already done this. So far it is working great, providing what I deem a third and final layer of caching for my system.

For those browsing this thread, again I want to remind you that this method we have been discussing is only one of at least three layers of caching that your system could employ. Given highly volatile pages it won't even work - but as long as your page generally remains the same for at least a minute it will diffidently prove useful.

However, more important than this method is the use of DB query caching and partial view caching (i.e. sidebar widgets). Memcached is your friend.
#13

[eluser]BrianDHall[/eluser]
[quote author="Xeoncross" date="1253740952"][quote author="BrianDHall" date="1253735683"]
Quote:For my money, if you want to really capitalize on caching enough to make it worthwhile you have a CI system that generates static real .html pages, you have an htaccess system that permits accessing a file directly if it exists (so the .html file doesn't get redirect if it really exists).

MoveableType took this approach and we see that it is causing performance problems for them. Imagine changing one sidebar link used on a site with 300 articles - you have to regenerate all those pages.[/quote]

Touche, a very good point. If you changed navigation you would need to regenerate an entire site, which could potentially be thousands of pages. That'd kind of suck.

Quote:
Quote:Hm, here's a thought thats more in line with the OP - what if you edited the index.php file to check for a cookie and then either served a cached page or static html page, or then proceeded with loading CI? Then the overhead is just a very small 1 page php script to check for the cookie.

Bingo. I have actually already done this. So far it is working great, providing what I deem a third and final layer of caching for my system.

For those browsing this thread, again I want to remind you that this method we have been discussing is only one of at least three layers of caching that your system could employ. Given highly volatile pages it won't even work - but as long as your page generally remains the same for at least a minute it will diffidently prove useful.

However, more important than this method is the use of DB query caching and partial view caching (i.e. sidebar widgets). Memcached is your friend.

Wow, an optimizer who actually knows what they are doing! Bravo!

In this case, it seems to me that you have a very good tool for specific scenarios where performance will matter to the tune of considerable amounts of money and usability. Like any tool its not a panacea or a works-anywhere-anytime approach, but for when it is needed it seems like a darn good solution.
#14

[eluser]InsiteFX[/eluser]
And what if the user has cookies TURNED OFF?

Enjoy
InsiteFX
#15

[eluser]kurucu[/eluser]
[quote author="InsiteFX" date="1253791593"]And what if the user has cookies TURNED OFF?

Enjoy
InsiteFX[/quote]
Then from a server point of view they will always be 'guest', never 'logged in' and so can always be served the cached pages. They would just perpetually be newly visiting users.

And if the site in question caters for identifying non-cookie people by using the query string, or any other method, then the pre-cache script can take advantage of that instead. I don't see a big problem.




Theme © iAndrew 2016 - Forum software by © MyBB