Re: high availability
| From: | jeremy brand | Date: | Tue, 07 Nov 2000 22:11:36 +0000 |
| Subject: | Re: high availability | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-24209@lists.php.net to get a copy of this message | ||
Just a little more on high performance. Images & cookie data.
Keep your images on a seperate machine (with a separate domain). See
how Yahoo does it. The images come from yimg.com. See how we do it:
http://www.care2.com/
The images are on
http://dingo.care-mail.com/
Here is the reason. Eventually, you will have more and more cookie
data used within your site. Unless there is a reason, and for us
there is none, peoples browsers are going to send all that cookie data
for every image requested if you keep your images on the same domain.
This happens (as we all know, right?) because web browsers send cookie
headers with each request to the given domain+path pair.
By keeping your images on a separate domain, that cookie traffic is
eliminated -- thus speeding up image loading because the total traffic
between the client and server is minimized.
By separating images from scripts, that also allows us to run a high
performance web server for images (thttpd) and use Apache for our
scripts. Apache is much more resource intensive, but needed (in
our case) for dynamic data:
headers from www.care2.com:
Server: Apache/1.3.12
headers from dingo.care-mail.com:
Server: thttpd/2.17 10may00
So, we have two added benifits which are a tremendous cost+performance
benefit.
-jeremy brand
http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html
for more
---------------------------------------------------------------------
We cannot do everything at once, but we can do something at once.
-- Calvin Coolidge
On Tue, 7 Nov 2000, jeremy brand wrote:
> Date: Tue, 7 Nov 2000 13:49:05 -0800 (PST)
> From: jeremy brand <jeremy@nirvani.net>
> To: alex <alex@quad.com.ar>
> Cc: michael@tapinternet.com, php-general@lists.php.net
> Subject: Re: [PHP] high availability
>
> We mount our web farms' docroot as an NFS share. AFAIK, this is
> pretty common.
>
> Our performance is excellent.
>
> -jeremy brand
> http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for
> more
> ---------------------------------------------------------------------
> We cannot do everything at once, but we can do something at once.
> -- Calvin Coolidge
>
> On Tue, 7 Nov 2000, alex wrote:
>
> > Date: Tue, 7 Nov 2000 18:52:32 -0300
> > From: alex <alex@quad.com.ar>
> > To: michael@tapinternet.com
> > Cc: php-general@lists.php.net
> > Subject: Re: [PHP] high availability
> >
> > > I'd suggest putting things in a database. Not used coda directly,
> > > but we tried a similar approach under NT writing info to shared drives,
> > > and the performance wasn't as good as sharing info in a db.
> > > CODA may be vastly different, but SQL makes more sense, imo.
> >
> > Looks like I made a little confusion about this. I was thinking on using
> > CODA for 2 purposes:
> > 1. store ALL the php scripts (since all web servers will have to use the
> > same copy of them)
> > 2. store php data (like php sessions)
> >
> > I understand that the php data can actually be stored on SQL and might be
> > better as you mention, but any idea how reliable will be to use CODA for
> > storing the php scripts itself ? (so I dont have to rsync all servers and to
> > avoid having a master/slave relationship between them)
> >
> > > How large of a system do you anticipate this being?
> >
> > I actually don't know for sure. but what I do know is that we need something
> > scalable in case of success =)
> >
> > Thanks for your comments.
> >
> > Alex Verstraeten
> > Buenos Aires,
> > Argentina
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net
> > For additional commands, e-mail: php-general-help@lists.php.net
> > To contact the list administrators, e-mail: php-list-admin@lists.php.net
> >
> >
>
>