On 28 December 2010 17:18, <knl@xxxxxxxxxxx> 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
