[FX.php List] Speeding up page display

[DC]

Bob,

I think you have misunderstood the point of caching in this case...  
you are correct that one reason to cache is to reduce server load  
when the same pages are loaded multiple times in succession. But,  
this time the prime reason to cache to HTML is to "completely control  
the rendering speed" not to "reduce strain on the server on multiple  
same page requests."

The idea is that *you* pull the page with a robot (or other page  
crawling mechanism) and cause the cache to be formed well before  
*anyone* hits that page. That way, no one but the robot sees the FMP  
speed (or lack thereof). Everyone else sees a speedy HTML page  
because you've told your robot to go and build the cache for you.

You would set a cache expiry time of "never" and only robotically  
rebuild the HTML page cache when you wanted to (weekends?).

Hope that clarifies my suggestion.
dan


On Aug 25, 2006, at 1:24 PM, Bob Patin wrote:

> Dan,
>
> Thanks for the reply; unfortunately, there are about 500,000  
> records that will be accessed, so I don't think caching will make  
> much difference except fo the few times when repeat queries are  
> done to the same record...
>
> However, I did add the flush commands, and they seem to be helping  
> a lot... the next step will be for the client to supply dedicated  
> machines for his site... :)
>
> Thanks,
>
> Bob Patin
> Longterm Solutions
> bob at longtermsolutions.com
> 615-333-6858
> http://www.longtermsolutions.com
>
>   CONTACT US VIA INSTANT MESSAGING:
>      AIM or iChat: longterm1954
>      Yahoo: longterm_solutions
>      MSN: tech at longtermsolutions.com
>      ICQ: 159333060
>
>
> On Aug 25, 2006, at 11:39 AM, DC wrote:
>
>> I've had a lot of success with using Smarty to help cache FMP  
>> results. Caching avoids a database call.
>>
>> http://smarty.php.net
>> also, check the wiki for a writeup a did a few years back with my  
>> specific requirements (which were similar to yours):
>> http://smarty.incutio.com/?page=CacheAndCompile
>>
>> If your HTML data doesn't change that much (meaning you're storing  
>> it in an FMP database because of organization rather than "update- 
>> ability"), Smarty has the ticket for you.
>>
>> It's a little learning up front but you should be able to get FMP  
>> results to cache within 1 or two hours of grabbing the Smarty  
>> codebase and following their great crash course.
>>
>> Of course, there are other, more basic caching systems out there  
>> that will help you write your FMP output into raw HTML to disk and  
>> have it served as raw HTML from then on unless you "flip a switch"  
>> to let the page request go to the database.
>>
>> try googling php caching tutorial
>>
>> dan
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.iviking.org/pipermail/fx.php_list/attachments/20060825/f93b8351/attachment.html