Fri, 20 Jun 08
Posted in Java, HTTP, PHP at 5:30 pm by moore
I am currently working on a project that uses a PHP CMS for the bulk of the site. However, it pulls some content from a page generated by JSTL on a tomcat. I was using the fmt tag to do some pretty printing of numbers, and it looked fine when I viewed the content as served by tomcat. However, none of the formatting was carrying through when the PHP page included the jsp. Why? It appears that the fmt tag needs a locale. I confirmed that with wget.
Now, how to set the header with the PHP include. The include man page was no help, and mod_rewrite won’t let you modify headers, as far as I can tell. Once the request arrived to tomcat, that was too late.
Some digging around in the PHP documentation on fopen turned up this gem:
Click through for a code example. The aforementioned documentation talks about custom headers, but it worked for sending the Accept-Language header that the fmt tags needed.
Permalink
Mon, 03 Mar 08
Posted in HTTP, Web Applications at 6:46 pm by moore
I recently placed squid in front of an Apache/Tomcat based web application to serve as a web accelerator. We could have used Apache’s mod_proxy, but squid has the ability to federate and that was considered valuable for future growth. (Plus, Wikipedia uses squid, and it has worked out pretty good for them so far.) I didn’t find a whole lot of other options–Varnish looks good, but wasn’t quite documentation and feature rich enough.
However, when the application generates a page for a user who is logged in, the content can be different than if the exact same URL is visited by a robot or a user who is not signed in. It’s easy to tell if a user is signed in, because they send cookies. What was not intuitive was how to tell Squid that pages for logged in users (matching a certain header, or a certain URL pattern) should always be referred to Tomcat. In fact, I asked about this on the mailing list, and it doesn’t seem as if it is possible at all. Squid caches objects at the page level, and can’t cache just pieces of a page (like I believe, among others, OSCache can).
I compromised by deleting the cached object (a page, for example) whenever a logged in user visits it. This forces squid to go back to the origin server, guaranteeing that the logged in user gets the correct version. Then, if a non logged in user requests the page, squid again goes back to the origin server (since it doesn’t have anything in its cache). If a second logged in user requests the same page, squid serves it out of cache. It’s not the best solution, but it works. And non logged in users are such a high proportion of the traffic that squid is able to serve a fair number of pages without touching the application.
Overall I found Squid to be pretty good–even with the above workaround it was able to take a substantial amount of traffic off the main application. Note that Squid was designed to be a forward proxy (for example, a proxy at an ISP caching commonly requested pages for that ISPs users), so if you want to use it as a web accelerator (in front of your website, to increase the speed of pages you create), you have to ignore a lot of the documentation. The FAQ is a must read, especially the section on reverse proxying and the logs section.
Technorati Tags: proxy, squid, increasing webapplication performance
Permalink
Thu, 30 Nov 06
Posted in Technology, HTTP at 10:57 pm by moore
It depends on how your website/web application is used, but browser caching can give you fantastic performance increases for very little effort. Especially with a database driven site that is primarily read-only (many ecommerce sites), proper browser caching can decrease the number of pages you serve per user, which in turn increases the number of users supportable by a given set of hardware.
I found this caching tutorial to be very helpful in understanding just how to cache pages, as well as RFC 2616, which states in section 13.2.4 that the Cache-control: max-age header takes precedence over the Expires header (for the browsers who speak HTTP 1.1). This examination of the support of various browsers is also excellent reading. There’s also a cool tool called the Cacheability Engine which examines caching behavior of web pages, if you don’t want to look at the headers yourself (using Fiddler or LiveHTTPHeaders). I encountered occasional errors with the engine, but it was pretty neat to use.
Technorati Tags: browser caching
Permalink
Tue, 31 Oct 06
Posted in Programming, HTTP at 8:42 pm by moore
Via this post I found Fiddler, which is a wonderfully easy way to see what IE is requesting. No need to use a proxy; you can see the requests as they happen. Simple install, which puts a fiddler button on the IE toolbar. Very useful for debugging. I haven’t tried it with IE7 and there was no mention of it on the Fiddler pages.
Permalink
