Slicehost Feeds Most Popular Stories

HTTP Accelerators and Dynamic Content

Thu, 23 Oct 2008 23:02:44 +0000

Hi all

I'm very new to the concept of reverse proxies and content accelerators and I wondered if someone who knows more could explain a fundamental question I have about how they work with dynamic content (in my case PHP generated pages). I suspect I'm being boneheaded or am missing the point so any enlightenment is much appreciated! :)

To keep things simple, suppose I have apache, php, mysql and varnish all installed on a single slice (in the real world I'd probably have more than one slice hosting these services). Everything is setup so that an incoming HTTP request for a php url hits varnish first and then (assuming a cache miss) gets sent back to apache and php for processing. As I understand it, the resulting generated php file is then sent to the client as assembled HTML and is cached (along with any css or images referenced by the HTML, if so desired) for x time period by varnish. If another request for the same php url comes in, varnish serves the already assembled HTML file together with any images and css from the cache rather than passing the request back to apache/php for processing.

My question is this:

Assuming that my understanding of http acceleration/content caching is correct, I can see how the above would work for php pages that are designed for anonymous viewing i.e. where limited (or no) personalisation takes place and any dynamic content is rendered exclusively from the use of POST and GET variables but how does this work for dynamic pages that include custom content based on session data? Is the answer that this sort of content is not cacheable or am I missing something?

The only answer I can come up with is that for SESSION based php pages the best you can do is cache the opcode (using APC for example). Is this right or am I making a fool of myself?

Final question: If am right, does this mean that you have to painstakingly tell varnish (or whatever caching app you use) which pages create content based on session data and therefore should be excluded from caching? This seems a bit error prone for larger sites where you may forget to explicitly mark one or two pages that mustn't be cached. [via http://forum.slicehost.com @ October 23, 2008 @ 11:02pm]

Email only server setup?

Fri, 14 Nov 2008 21:23:56 +0000

Hello all,
I am going to be moving from my current host to a different dedicated server hosting. But I am now worried about warming up my new ip address and email deliver ability. I am currently sending out about 15,000 emails a month (all transactional, we use an external service for newsletters). I am just wondering if anyone has hosted just your email servers here? That way if/when we change hosting providers again we don't need to worry about the email thing. Also is getting more ip address hard? We are growing at about 25% a month so at some point kinda soon we would need to start splitting the traffic between a few ip address.

Thanks
Matt [via http://forum.slicehost.com @ November 14, 2008 @ 9:23pm]

Recipe for deprec php nginx rails mysql

Sat, 15 Nov 2008 05:29:18 +0000

Hi everyone, I've done some searching, and I haven't found anything.

I'm looking for a deprec capistration recipe for setting up my slice using nginx, php, mongrel, monit, mysql, rails.

Anyone have any suggestions? [via http://forum.slicehost.com @ November 15, 2008 @ 5:29am]

API slice element needs billing start date

Fri, 19 Sep 2008 02:39:19 +0000

I'm playing with the API (v1.4) -- very nice!

My plan was to write a small python app that would periodically look at the <bw-out> of a <slice> and alert you if a slice's extrapolated network traffic was projected to exceed its monthly budget. The only thing missing for this is the slice's billing day. Without that, I can't tell how much time the given <bw-out> has had to accrue, and hence can't compute the rate.

What about adding an e.g. '<billing-start>' element that gives the day of the month on which the slice's traffic count is zeroed?

Thanks kindly. [via http://forum.slicehost.com @ September 19, 2008 @ 2:39am]