A hint on e-mail speeds

I've seen it bandied about here on the forums that there is a way to get around the 20 second delay for llEmail. Can anyone point me in the right direction?

Multiple scripts.

That enough of a point in the right direction?

Have a rezzed prim from inventory send the email and then die?
(after first having params passed to it from a one-time listen)

send data from the server object to a website and have the clients read the website instead of looking for the next email

Unless you're hitting the per-prim email limit you can just put all the scripts in the same prim and communicate between them with link messages. It's faster and more secure.

I second this method. This is how I get around the e-mail limit in my projects. I'd be careful with this though because if you're constantly firing off many e-mails in the run of 20 seconds, your object may get flagged by Linden Lab and will no longer send e-mail. I've never experienced this personally but I've heard it's possible.

I have a bank of 20 mailers and throttle the output to 1 mail/sec in the dispatcher. Works since several weeks ago without noticing any Linden action. However, the average throughput is well under 60 mails/min.

In an attempt to reduce sim load, I stop each mailer after llEmail (llSetScriptState(llGetScriptName(),FALSE)) and have the dispatcher wake them up before sending.

This was a big help, thanks guys. I'm puzzling out the logic of it now. I'm planning on a bank of 5 mailers. What's your opinion of the optimum number?

It depends on your needs. 5 mailers will give you an average rate of 15 mails/min or peaks to 4 sec/mail (easy math. You have to throttle throughput to the last number in the upper layer or implement a queue. I would never try to go over 20 mailers, but use HTTP instead.

Also, handling wrong keys is a problem in the long term. If you use mail, we assume that objects are owned by others or placed on foreign lands. It is easy to loose track of all your objects, how much they are and where. You don't get mail bounces, so you can't say if you are sending to a non-existent or derezed object.

A protocol may help : implement a PING command and, if the object does not answer, disable its key in the database. I've made region name and location part of the message at the transport layer, so each message is flagged with the transmitter's location.

Interesting. Thank you, Jeff.

*edit* I had independently come to the conclusion that 5 to 10 was going to be optimum for the number of mailers.