Database options to lower bandwidth

> Reducing the amount of HTML in a page *does* save bandwidth. If there
> are images: optimize them.

It's hard to believe, but I only have about 10 images on the site, and
those are on the homepage (except for a 10x10 spacer.gif image). Even
the logo is served with CSS. I do serve a handful of ads, but they're
pulled from a different server so they don't count towards the
bandwidth. So literally all of the bandwidth is from text.

> Databases are good at handling stuff like this, if designed good.

I really know little about good database design, but since this
probably isn't an appropriate topic for this NG, I'll take this
conversation to a MySQL NG.

> Check your HTML. There is an Apache module that compresses HTML for
> browsers that can handle it. Might save quite some bandwidth.
>
> However, 50G/month shouldn't cost you more then a few bucks a week.

Even though the host I use is excellent for customer service and
uptime, they don't have good rates for bandwidth. Their largest option
allows for 30GB for $29.95, but then there's a charge of $6 per GB
over. My last invoice was $84, and my next one will be considerably
higher.

I've considered changing hosts, but I can't afford to risk the site
going down for 24-48 hours while the nameservers transfer, either.
Tough one.

I'll look into the Apache module, thanks.

Jason
 >> Stay informed about: Database options to lower bandwidth 

"Jason" <jwcarlton.DeleteThis@gmail.com> wrote in message
news:1133133728.342315.237490@g49g2000cwa.googlegroups.com...
> My website includes a message board program (my own design) that
> utilizes a series of text files for data. Each subject creates a new
> text file, and the posts are saved in this text file.
>
> This worked out great in the beginning, but now the site has grown
> substantially to the point that I have more than 4000 of these text
> files taking up about 30MB of space. I've recently attained regional
> notice, and my site is growing... fast.
>
> I was told by my hosting provider that my monthly bandwidth is now at
> about 50G a month, and growing exponentially. I'll have about 5 million
> page views in a month... this is getting to be expensive!


Your problem probably isn't going to be bandwidth, shortly, but server
resources. If you're running a message board and pulling in that kind of
traffic now, I wouldn't be surprised if your site is going to cause the
server its on to slow soon. Talk to your host and find out what options are
going to be available for you in the near future.

--Tina
 >> Stay informed about: Database options to lower bandwidth 

"Jason" <jwcarlton.DeleteThis@gmail.com> wrote in message
news:1133133728.342315.237490@g49g2000cwa.googlegroups.com...
> My website includes a message board program (my own design) that
> utilizes a series of text files for data. Each subject creates a new
> text file, and the posts are saved in this text file.
>
> This worked out great in the beginning, but now the site has grown
> substantially to the point that I have more than 4000 of these text
> files taking up about 30MB of space. I've recently attained regional
> notice, and my site is growing... fast.
>
> I was told by my hosting provider that my monthly bandwidth is now at
> about 50G a month, and growing exponentially. I'll have about 5 million
> page views in a month... this is getting to be expensive!

Add this php to the top of each hmtl file served:

<?php ob_start("ob_gzhandler"); ?>

That ought to cut your bandwidth by at least half.

Anthony Wieser
Wieser Software Ltd
 >> Stay informed about: Database options to lower bandwidth 

"Jason" <jwcarlton RemoveThis @gmail.com> wrote in message
news:1133152874.230268.108710@g44g2000cwa.googlegroups.com...
>> Reducing the amount of HTML in a page *does* save bandwidth. If there
>> are images: optimize them.
>
> It's hard to believe, but I only have about 10 images on the site, and
> those are on the homepage (except for a 10x10 spacer.gif image). Even
> the logo is served with CSS. I do serve a handful of ads, but they're
> pulled from a different server so they don't count towards the
> bandwidth. So literally all of the bandwidth is from text.
>
>> Databases are good at handling stuff like this, if designed good.
>
> I really know little about good database design, but since this
> probably isn't an appropriate topic for this NG, I'll take this
> conversation to a MySQL NG.
>
>> Check your HTML. There is an Apache module that compresses HTML for
>> browsers that can handle it. Might save quite some bandwidth.
>>
>> However, 50G/month shouldn't cost you more then a few bucks a week.
>
> Even though the host I use is excellent for customer service and
> uptime, they don't have good rates for bandwidth. Their largest option
> allows for 30GB for $29.95, but then there's a charge of $6 per GB
> over. My last invoice was $84, and my next one will be considerably
> higher.
>
> I've considered changing hosts, but I can't afford to risk the site
> going down for 24-48 hours while the nameservers transfer, either.
> Tough one.
>
> I'll look into the Apache module, thanks.

All you need to do is find a host that allows you to change the A record on
the domain. Sign up, immediately change the A record to point back to the IP
of your other host. Change the nameserver information to point to the new
nameservers. Let propogation take place, and it won't matter because both
are pointing to the old server. Wait a couple days, change the A record on
the new server back to the original IP it was set at (pointing to itself)
right after you move the files to the new server. Traffic will instantly be
diverted to the new server.

I would watch out going with someone who oversells. You will run into
trouble, because there is a price in hosting a site that uses 50GB, and even
though they advertise 50GB for 10 cents a month, you may soon get booted if
you actually try to use it. It's actually not the bandwidth that is the
problem it is the processor time involved in delivering it. I'd get a
dedicated server if I had a site pushing 50GB because you will need it
eventually if the growth rate is what you say it is.
 >> Stay informed about: Database options to lower bandwidth 

On Mon, 28 Nov 2005 21:26:44 GMT, "Jim S." <mail RemoveThis @page-zoneRMTHIS.com>
posted something that included:

> I'd get a
>dedicated server if I had a site pushing 50GB because you will need it
>eventually if the growth rate is what you say it is.

To quote Groucho Marx, "Two thousand dollars for ice? I can get an
Eskimo for two hundred dollars and make my own ice."

There's a big difference between renting space on someone else's
server and getting your own. The difference is hiring a sysop.

We spend *far* more money on support than it costs us for servers and
bandwidth. Some of the support is doing stuff customers can't do for
themselves ("I accidently uploaded a file with a space in the name,
and my FTP software, I can't delete it!"), some of the support is
answering questions customers can't ask anyplace else (Where is
"mogrify" located?), some of the support is answering questions
customers should ask elsewhere ("Why is </table> mandatory and </td>
optional?") but a lot of it is resolving issues ("Since you upgraded
MySQL, my mail is bouncing!")

Some of my best customers used to have their own servers, until they
found out what having their own server is all about.

I have sites pushing 75 to 100 GB per month, and they aren't a
problem. On the other hand, I have sites that only use 5 GB of
bandwidth, but they are constant problems because they keeping writing
poorly-designed software that bogs down the server.

Bandwidth is *incredibly* cheap if you're in a good data center. We
probably contract for 3-4 times as much transfer as we use. And a
hosting company that chases away a customer because they're using too
much bandwidth is managed by dolts. If the customer is bogging down
the server, and fails to learn, that can simply be a lack of patience,
but that's another issue in any case.

BTW, flat files are intrinsically "cheaper" in terms of server
resources than database files, unless you need to do database
operations like sorting or searching, in which case they can be
incredibly "expensive".

The easiest way to move from one server to another is to set up a
subdomain on another server that everything gets redirected to; that
is, when people come to www.mysite.com, they get redirected to
alpha.mysite.com. You set up a second www.mysite.com on the new
server as well, and after 30 days, you drop the first site.

(You *should* be able to set the DNS to expire after 10 minutes, wait
a couple of weeks, then change the A record to the new server, but
there are a lot of ISPs running DNS boxes that ignore TTL, and you'll
have people getting sent to the old server for 30 days, no matter how
well you make your own DNS dance.)

Paul Ding
AmishHosting.com


















--
If we're losing 40-130 species a day,
How come nobody can itemize them?
And why can't fruitflies be one of them?
 >> Stay informed about: Database options to lower bandwidth 

Writing in news:alt.www.webmaster
From the safety of the No thank you cafeteria
Charles Sweeney <me.DeleteThis@charlessweeney.com> said:

> John Bokma wrote
>
>> Nah, add a timestamp column to the table that holds the subjects. IIRC
>> MySQL has a kind of auto-timestamp option, which is updated if you set
>> it's value to NULL.
>
> Correct. I use it. I can't remember off the top of my head, but I
> vaguely
> recollect problems with this if it's not the last field in the table.

is it a real 'timestamp' or simply an auto-generated datetime value? I
mention it because timestamps tend to be unique (in the context of table,
maybe db) which incurs its own overhead.

--
William Tasso

Save the drama
for your Mama.
 >> Stay informed about: Database options to lower bandwidth 

"Paul Ding" <lancastir RemoveThis @paulding.net> wrote in message
>
> The average good self-employed sysop has to pull down $175/hour to
> match the $85,000 he can make as an employee - and that's about what a
> $35 charge for running /scripts/easyapache on a cpanel box comes to.
> I'm average-good, and that's what I charge regular clients. If you
> come to me as a stranger in an emergency, it can be twice that.

Real entertaining. You consider yourself average and charge how much in an
emergency? $350/hr. Pffff.
I wouldn't hire you even as a front line tech. Because you don't know Jack,
and what you think you know would be spotted as bullshitting by even my most
technically deficient customer.
 >> Stay informed about: Database options to lower bandwidth