UTL_MAIL performance

Question

We have requirements to send large number of emails from database (up to 50,000 emails in single batch). A database is 11g and it's on Unix HP server with a lot of available resources. The emails will go through Microsoft exchange Server. Some of the initial testing shows that utl_smtp has 20% better performance than utl_mail by keeping connection open. utl_mail performance is about 0.4 second per email per single thread. So, yes, we can have several threads going, but is there anybody there that has similar performance like we do in case of sending large number of email? The performance from unix script is about 0.15 second and it similar from Java program running from desktop. It look that majority of time is spent on establishing communication with exchange server. Can any of utl_mail parameters/options be modified? Can we keep communication open instead of opening and closing channel with Exchange server every time? TIA

Answer 1

If you want performance and flexibility for sending e-mails, then I would use UTL_TCP directly - not UTL_SMTP and especially not UTL_MAIL.
PL/SQL code using UTL_TCP will be on par with similar code in another language using tcp sockets to send mail.
Of course, you need to use the same methods for optimisation. Do not close and re-open a socket per e-mail as this requires re-authentication with the mail server. Do not duplicate the DATA command when the same mail is send - simply use multiple RCPT TO commands to specify all the recipients of that e-mail. If the same attachment needs to be send via different mails, build that as a CLOB (already packaged as a Mime fragment) up front and persist it (store in table) so that multiple mail processes can simply use it as is. Etc.
If the contents of the e-mails are created from the data in the database, then PL/SQL will likely be faster sending the e-mail in comparison with other methods and even bulk mail products.
Such code need to fetch the data from the database - this means data traveling across process boundaries or even machine boundaries. PL/SQL code runs in the same server process as the SQL engine. That is as close to SQL data as one gets. The path for the data to travel from the database to application code is therefore a lot shorter.