On 29 December 2010 16:34, Richard Quadling <rquadl...@gmail.com> wrote:
> On 28 December 2010 17:18,  <k...@bitflop.com> wrote:
>> Hi.
>> I am currently looking into improving a system that (like many systems)
>> generate static content at runtime.
>> I have always been against generating static content at runtime and
>> believe static content should be generated by a cronjob or manually at
>> some idle time (if possible).
>> This will provide real static content (no PHP at all) that doesn't need
>> to be checked every time a request is made hence a huge performance
>> benefit is achieved.
>> A nice article on the issue:
>> http://zoompf.com/blog/2009/12/the-challenge-of-dynamically-generating-static-content
>> Quote: "The moral of the story is never make the user pay for your
>> laziness. Do not use the application tier of a website to dynamically
>> generate static content at runtime. Instead do it at publishing time or
>> even do it in a daily or hourly cron job. This approach allows you all
>> the advantages of using application logic without drastically reducing
>> the very web performance you were trying to improve in the first place!"
>> Sometimes however many pages are linked together and when working with
>> a system with hundreds or thousands of pages re-creating a lot of
>> content each night perhaps isn't always the best way to do things.
>> Especially if the content needs to be updated right away and can't wait
>> for the nightly cronjob to do its business.
>> To illustrate with a simple example..
>> A blog system with a menu that displays how many posts exists in each
>> category.
>> - Home
>> - About
>> - Tech (412)
>> - News (2030)
>> etc.
>> When a new page is added to the News category every single page in the
>> system needs to get updated in order for the menu to display the new
>> number (2031).
>> Some use a compromise to include only changing items (like the menu
>> in the above example), but that would mean using PHP and not serving
>> pure static content.
>> Others use "ugly" solutions like frames.
>> Care to share your experiences and recommendations on the issue?
>> Kind regards
>> ---
>> Kim N. Lesmer
> As mentioned, using http://en.wikipedia.org/wiki/Server_Side_Includes
> is going to be the simplest way to deal with semi static data.
> When a new post is added, you update the text file (posts.txt), making
> sure you handle all the locking so that 2 posts at the same time don't
> end up as only 1 increment.
> If you find that the locking is taking too much time (which would
> indicate a lot of new posts simultaneously), only update the file if
> you can get an exclusive lock. By the time you've failed, a few more
> posts will have gone in and the file will have been unlocked at some
> stage and then updated.
> For something like a post count, I wouldn't consider this to be too
> important to be kept 100% accurate. As long as the only usage is to
> display to the user. If you need a realtime update, then the DB can
> provide it along with an AJAX refresh of the <span id="postCount" />
> element. If needed.
> For things like CSS and JS, these tend to be static and should
> probably be stored combined/minified/gzipped. Here is an old article I
> used to help me get rid of the JS and CSS loading on my servers :
> http://rakaz.nl/2006/12/make-your-pages-load-faster-by-combining-and-compressing-javascript-and-css-files.html.
> So, a page load will get 1 HTML, 1 CSS and 1 JS call to the server.
> The CSS and JS will be client side cached. For the first hit, the CSS
> and JS will be minified and gzipped, so lowering your bandwidth usage.
> I've never tried it, but I think you can also do something similar for
> images. Rather than 1 request per image, 1 image per page request (or
> fewer images per page request). http://www.quate.net/newsnet/read/48
> and http://www.websiteoptimization.com/speed/tweak/combine/
> So, that deals with a lot of request issues that the server is no
> longer needing to deal with on every single page.
> The server side includes for the semi-static text.
> --
> Richard Quadling
> Twitter : EE : Zend
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

http://ruweb.wordpress.com/2006/08/23/combine_images_web2_ajax/ (In
russian, but Google Chrome happily translated this into readable

Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to