On 5/12/01 7:20 PM, "Tib" <[EMAIL PROTECTED]> wrote:
> To take another approach, mail out a link to the newsletter rather than the
> ENTIRE newsletter to each person. Do the math;
Your math is wrong, though.
> if you're mailing out a letter
> that's 30k, to 10,000 users. that's gonna be 300 megs of data that's getting
> pumped through your system, on a weekly basis, with each one having a
> possiblity of becoming corrupt or having other failures in transfer.
> First of all it'll cut
> your data output through the mailserver IMMENSELY, a 1k message that goes out
> rather than 30k will only end up being 10 megs rather than 300. Second, the
> time it takes to SEND that batch of messages will be drasticly reduced.
There are any number of problems with this.
First, if you have a measley 384K DSL connection, you can send out 300 megs
of data in about 2.5 hours. It's just not a big deal from the start.
Second, you're ignoring the economies of scale that comes from SMTP putting
this together. If you set your SMTP_MAX_RCPTS to 10, which is still a fairly
small number, then any domains that have 2 or more subscribers get lumped
together, and the newsletter gets sent once to each domain. If you have more
than ten subscribers to a domain, it gets sent once for every ten
subscribers, a 90% reduction. If the list is at all typical, you'll be
sending 25% or more less than a simple mathematical multiplication might
assume.
Third, you ignore the overhead of the SMTP protocol -- there's control data
that goes along with the content data. Not much, but it'll add to the time
somewhat.
Fourth, and most important -- you're ignoring the overhead imposed by SMTP
and the acceptance speed of the client systems. Those are significant, and
tend to make the actual size of the message (within reason) not all that
significant. For a non-optimized system, I'd say the difference in delivery
time of 10,000 subscribers for a 2-3K message and a 30K message is probably
double, not the 10X or more you'd imply by simply looking at the size
difference. If you have a fast network connection and figure out how to
optimize your delivery setup, then for small lists like this, your primary
delay vector is the speed the other side is willing to accept it. On my big
server, where 40,000 is my smallest list, I literally can't get the system
up to speed before it's delivered, and for something that size, my big
limiter is the speed other systems respond to my delivery request.
And there are logistic problems to your suggestion -- if you send a URL to
the users instead of the message, the number of eyeballs that person's
advertisers will get plummets by a huge fraction. Send URLs, and many users
won't bother much of the time. It's a really bad idea for most environments,
especially if they're doing newsletter or marketing oriented stuff.
> And
> last, if you have to make any changes to the message or find a critical
> editing
> error AFTER it's out,
A legitimate issue, but one which you mostly deal with by making sure you
edit the thing properly the first time. Sometimes URLs change, but there are
ways to deal with that (but I can't talk about how I did it, at least not
right now).
> Downside? I don't really see any big ones. This type of change would only
> require that you have a web server resource to point this at.
Downsides:
1) you're forcing the user to make an action to read the newsletter. If you
give users an excuse, they'll take it. Your actual readership will plummet,
not good for the advertisers. Any little hassle is still a hassle.
2) it requires having a web server and a network connection that can handle
the PEAK load when everyone clicks the URL at the same time after you
deliver it. You'll see 50-70% of those users click through in the first 90
minutes after delivery of the URL, so you probably need a faster link than
you'd need to deliver the actual message, since delivery of a piece of
e-mail isn't peak-load sensitive (the receiver doesn't care all that much if
they get it now or in two hours from now) -- but web stuff is (if they get
that URL now, and the server is overloaded, you're toast). In fact, if you
start doing newsletters with a lot of clickthrough stuff to a central
server, I've found it's best to SLOW DOWN delivery to spread out the load on
your web server.
3) remember all that bandwidth you thought you saved by going with the small
piece of e-mail? You just gave it all back (and probably more) via the web
server. But instead of it going out in a controlled manner because you're
pushing email, it's going out in a demand manner, because now they're
pulling it on THEIR schedule, not yours. Which means you need a faster net
link and bigger web server to handle the peak load, because the users won't
wait.
That kind of delivery model is a false economy. That content is going to go
out the network somewhere, sometime. Send it out by e-mail, it goes out on
your schedule. Send out links and wait for web clicks, it goes out on THEIR
schedule -- and they're going to pile on quickly after delivery because
that's when the user wants it. And you haven't saved any of your network
bandwidth, you've simply bunched it into a peak load, which is worse for you
and your customers.
It seems logical to send smaller messages -- but that data's going out
sooner or later, so it's really a false economy, and it doesn't work in
practice, because the users don't cooperate. Once they get a link, they
either throw it out, or they want to read it NOW, and that really hoses over
your network and web server unless you have capacity to deal with it. And
for a small network, it's more expensive to do that than to send out the
mail in the first place a little slower. Unless your content is VERY time
sensitive, it makes no sense (and if it is time sensitive, it STILL makes
sense to sned it via email, but to spend your money making your email as
fast as possible, which probably means hiring someone like me to build the
network for you. (note: I'm not allowed by my employer to consult on email
for pay, so don't ask. And besides, I'm fully scheduled out for the year
already)
This is something where you really need to do this stuff before advising
people how to do it, because some of the things that are "obvious" don't
work in practice...
Chuq
------------------------------------------------------
Mailman-Users maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
