On Wed, Aug 29, 2012 at 6:06 PM, Stan Hoeppner wrote:
> On 8/28/2012 1:13 PM, Viktor Dukhovni wrote:
> > On Tue, Aug 28, 2012 at 11:48:19AM -0500, Stan Hoeppner wrote:
> >
> >> So maybe for this particular application a ramdisk isn't a horrible
> >> idea. But he still has the problem of implement
On 8/28/2012 1:13 PM, Viktor Dukhovni wrote:
> On Tue, Aug 28, 2012 at 11:48:19AM -0500, Stan Hoeppner wrote:
>
>> So maybe for this particular application a ramdisk isn't a horrible
>> idea. But he still has the problem of implementing parallel submission
>> in his java application, otherwise it
On Tue, Aug 28, 2012 at 11:48:19AM -0500, Stan Hoeppner wrote:
> So maybe for this particular application a ramdisk isn't a horrible
> idea. But he still has the problem of implementing parallel submission
> in his java application, otherwise it won't matter if it's a ramdisk or
> an old 3600 RPM
On 8/28/2012 8:16 AM, Mike wrote:
>
>
>> The first thing that comes to mind is using a ramdisk for the queue
> directories.
>> But I'm doubting Postfix will work with queue directories on a
> ramdisk. Wietse can answer this.
>
> There's no reason Postfix won't work with /var/spool/postfix mounte
> The first thing that comes to mind is using a ramdisk for the queue
directories.
> But I'm doubting Postfix will work with queue directories on a
ramdisk. Wietse can answer this.
There's no reason Postfix won't work with /var/spool/postfix mounted
from RAM. The standard filesystem(s) used
All this makes perfect sense, thanks for the additional detail, Stan.
/mike
On Aug 27, 2012, at 12:06 PM, Stan Hoeppner wrote:
> I'm copying this response back to the list, as this discussion needs to
> be in the various list archives for other who may intend to follow in
> your footsteps.
..
I'm copying this response back to the list, as this discussion needs to
be in the various list archives for other who may intend to follow in
your footsteps.
On 8/27/2012 8:09 AM, Mike Mitchell wrote:
> I do have to say, I was originally hoping that I could optimize things
> merely with some main.
Thanks, Stan--working on it!
/mike
On Aug 26, 2012, at 12:06 AM, Stan Hoeppner wrote:
> Did you get a chance to digest my suggestions on this yet? I gave you
> nearly everything you need to know implement this with Postfix, sans
> rewriting the JAVA app for parallel submission.
>
> --
> Stan
On 8/24/2012 10:05 AM, Mike Mitchell wrote:
>
> On Aug 24, 2012, at 8:11 AM, francis picabia wrote:
>> On Thu, Aug 23, 2012 at 1:33 PM, Mike Mitchell wrote:
>>> I am attempting to configure a postfix server to handle really high-speed
>>> mail delivery. This means I'll be sending (via Java API
On Aug 24, 2012, at 8:11 AM, francis picabia wrote:
> On Thu, Aug 23, 2012 at 1:33 PM, Mike Mitchell wrote:
>> I am attempting to configure a postfix server to handle really high-speed
>> mail delivery. This means I'll be sending (via Java API) potentially tens
>> of thousands as fast as poss
On Thu, Aug 23, 2012 at 1:33 PM, Mike Mitchell wrote:
> Hi all,
>
> Fairly newbie user here (okay, waiting for collective groan to die down).
>
> I am attempting to configure a postfix server to handle really high-speed
> mail delivery. This means I'll be sending (via Java API) potentially tens
On Aug 23, 2012, at 22:40, Mike Mitchell wrote:
> On Aug 23, 2012, at 3:32 PM, Wietse Venema wrote:
>> You announced yourself as fairly newbie (your own words). Therefore
>> I gave you my honest advice of "don't do it".
>
> I'm willing to accept that I asked for it. :-) I perhaps over-emphasi
On 8/23/2012 7:29 PM, Wietse Venema wrote:
> Mike Mitchell:
>> The first issue I know is being reported is seemingly a throttling
>> of submissions to the server--we can send about 50, then we're
>> made to wait almost exactly 6 seconds, then we can send about 50
>> more.
>
> This is a built-in sa
Mike Mitchell:
> The first issue I know is being reported is seemingly a throttling
> of submissions to the server--we can send about 50, then we're
> made to wait almost exactly 6 seconds, then we can send about 50
> more.
This is a built-in safety feature.
If a client were allowed to flood Pos
On Aug 23, 2012, at 3:32 PM, Wietse Venema wrote:
> You announced yourself as fairly newbie (your own words). Therefore
> I gave you my honest advice of "don't do it".
I'm willing to accept that I asked for it. :-) I perhaps over-emphasized my
newbie-ness in order to prompt more of an overvie
Zitat von Mike Mitchell :
We've actually been providing this service for 10 years now, but are
just now reaching a scale where default configurations are
insufficient to handle the volume. We've not needed to touch the
mail server prior to now, so are just looking for some initial
guid
Mike Mitchell:
> We've actually been providing this service for 10 years now, but
> are just now reaching a scale where default configurations are
> insufficient to handle the volume. We've not needed to touch the
> mail server prior to now, so are just looking for some initial
> guidance as we d
On 8/23/2012 2:06 PM, Mike Mitchell wrote:
> We've actually been providing this service for 10 years now, but are just now
> reaching a scale where default configurations are insufficient to handle the
> volume. We've not needed to touch the mail server prior to now, so are just
> looking for
We've actually been providing this service for 10 years now, but are just now
reaching a scale where default configurations are insufficient to handle the
volume. We've not needed to touch the mail server prior to now, so are just
looking for some initial guidance as we dig into optimization.
Mike Mitchell:
> Hi all,
>
> Fairly newbie user here (okay, waiting for collective groan to die down).
>
> I am attempting to configure a postfix server to handle really
> high-speed mail delivery. This means I'll be sending (via Java
> API) potentially tens of thousands as fast as possible (spe
20 matches
Mail list logo
