Re: [PHP] Static content at runtime
On Tue, 28 Dec 2010 23:25:57 -0600 Donovan Brooke li...@euca.us wrote: and btw, I found that Billy Hoffman article to be inaccurate in many of his assertions. Would you mind sharing in what ways you found his assertions inaccurate? Kind regards, Kim Cheers, Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static content at runtime
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static content at runtime
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 English). -- 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
Re: [PHP] Static content at runtime
k...@bitflop.com wrote: On Tue, 28 Dec 2010 23:25:57 -0600 Donovan Brookeli...@euca.us wrote: and btw, I found that Billy Hoffman article to be inaccurate in many of his assertions. Would you mind sharing in what ways you found his assertions inaccurate? Kind regards, Kim Cheers, Donovan -- D Brooke Well sure.. I have some time.. it's the holidays. ;-) I don't entirely agree with the premise first of all... I think serving dynamic content at runtime works well 90% (loose figure) of the time and ultimately creates a system that is easy to troubleshoot and maintain, and which always has realtime accurate data. I should first preface my comments that I am not against a publishing system, nor a caching system when the project needs, or growth/performance needs, would require (or could benefit from) it.. however, I also believe that those requirements are a small portion of the projects/jobs out there these days. The author says: Since the web server is not serving a static file, there will be no Last-Modified header sent by default. That means no conditional GETs and no 304 responses which means lots of bandwidth consumption. That is not quite accurate.. a programmer can force http headers. PHP, like virtually all application tiers, produces a chucked response. This is because the web server has no idea what the content length will be because it is dynamically generated. Dynamically generated chunked responses will not send the Accept-Range header. This means no pausing or resuming or error recovering. The entire resource must be re-downloaded. First, I think he means Accept-Ranges header.. and as in my previous comment, a programmer can manipulate http headers... which makes some of his other reasoning not quite accurate. Lastly he proceeds on to illustrate a dynamic resource (http://example.com/combine.php?files=a.js|b.js|c.js), apparently, as a a reason why serving dynamic content is not as good as serving static content (for security reasons). At this point, it's really just him showing off his ability to spot hackable code I think. ;-) My answer to that is that it has nothing to do with runtime code vs. published static content, and everything to do with the noob programmer who decided to make a hackable get request a part of their app. Overall, to me that article may provoke some good thought.. but I would treat it like Rush Limbaugh.. don't buy into all of it. Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static content at runtime
Care to share your experiences and recommendations on the issue? It seems to me that you ask a great question, and ask it well. I have worked on both kinds of systems. But I am not expert enough to say anything definitively. Just one thought I had while thinking about it: How about: publish static content.. and for the changing menu number, use Ajax instead of PHP include(s). Would that be any better? ...or maybe it is effectively the same dynamic burden in the end? Govinda -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static content at runtime
On Tue, 2010-12-28 at 13:25 -0500, Govinda wrote: Care to share your experiences and recommendations on the issue? It seems to me that you ask a great question, and ask it well. I have worked on both kinds of systems. But I am not expert enough to say anything definitively. Just one thought I had while thinking about it: How about: publish static content.. and for the changing menu number, use Ajax instead of PHP include(s). Would that be any better? ...or maybe it is effectively the same dynamic burden in the end? Govinda I'd tend towards server-side includes handled by Apache instead of Ajax if you're that worried about dynamic content cost. It's faster than have PHP produce the entire page each time as it's only using Apache instead of Apache and PHP. Aside from that Ajax shouldn't be used for this sort of thing. Not everyone has Javascript enabled, a lot of search engines won't process the content pulled in via Ajax (Google does handle some Javascript now to a limited extent) and it takes extra time for a clients browser to load the Javascript that is being used, and then it has to make the request and wait for the response, all of which takes time. It might seem fine in local testing, but in the real world on a variety of connections it doesn't work the way you want. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Static content at runtime
The other option is to generate the page dynamically and cache it (we use Varnish) for the next users. This way you pay the cost to regenerate pages only for those someone views--and only once. This pays off well when you have high traffic. David
Re: [PHP] Static content at runtime
On 2010-12-28, at 2:19 PM, David Harkness davi...@highgearmedia.com wrote: The other option is to generate the page dynamically and cache it (we use Varnish) for the next users. This way you pay the cost to regenerate pages only for those someone views--and only once. This pays off well when you have high traffic. David Yep. Been there, done that! Got massive increases out of the system by using that process. Bastien Koert Sent from my iPhone -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static content at runtime
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. Does your needs really call for a publishing system at all? Back in the day, machines were slow and search engines didn't like much of the URL past the ?.. thus creative app design was needed to get around these issues, such as publishing systems and caching etc... Since it was stated you are improving a system.. I thought this would be something to consider. Today, it's a lot easier to create a punctual, scalable, and search engine friendly app that doesn't use a publishing system (nor caching). Anyway, my point is sometimes improving a system, can mean making it simpler. If publishing or caching is not needed, why complicate the matter?.. and btw, I found that Billy Hoffman article to be inaccurate in many of his assertions. Cheers, Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
