Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51806 > unrolled thread

Re: Python performance

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python performance Schneider <js@globe.de> - 2013-08-02 15:16 +0200

#51806 — Re: Python performance

On Fri 02 Aug 2013 02:59:26 PM CEST, Tim Chase wrote:
> On 2013-08-02 14:00, Schneider wrote:
>> I have to write a small SMTP-Relay script (+ some statistic infos)
>> and I'm wondering, if this
>> can be done in python (in terms of performance, of course not in
>> terms of possibility ;) ).
>>
>> It has to handle around 2000 mails per hour for at least 8hours a
>> day (which does not mean, that it is allowed not to respond the
>> r
est of the day.
>>
>> Can this be done? or should I better use some other programming
>> language? My second choice would be erlang.
>
> I suspect it depends on a lot of factors:
>
> - will your network connection support that much traffic?  (And an
>    ISP that will grant you permission to spew that volume of email?)

yes, because we are the ISP.

> - are these simple text emails, or are they large with lots of
>    attachments, inline images, PDFs, or whatever?

any kind of mail. No restrictions allowed.

> - are the statistics that you're gathering simple, or do they require
>    complex analysis of the documents passing through?

very simple statistics, mostly counting and time statistics.

> - is the load 8hr straight of spewing email, or is it bursty?  If
>    it's bursty, you can internally queue them up when load gets high,
>    delivering them from that queue when load diminishes.  Given the
>    store-and-forward nature of email, there's no guarantee that if
>    you spewe
d them at ~33/minute (that/s a little faster than one
>    every two seconds), they'd arrive at their destination any faster
>    than if you'd queued them up and sent them at a more steady rate.

I guess it's bursty. I don't have finer granulated information about 
their time distribution.

> -tkc
>

Queuing the mails for a while is not possible, because the tool should 
sit between the client and smtp-server.
It should act as proxy, not as server.

bg,
Johannes



--
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web