Curso Taller
Especializado - Control de la Planta de ProducciónBogotá 12 y 13 de
junio, 2014
El control de la planta de producción es un
elemento crucial en el proceso de la manufactura, ya que tiene el poder de
hacer o deshacer la operación por completo. La planta de producción, bien
con
On Tue, May 27, 2014 at 08:27:52PM +0200, Jakov Sosic wrote:
> On 05/27/2014 08:21 PM, Willy Tarreau wrote:
>
> >What is happening here is simple : the client disconnected before the
> >connection to the server managed to complete ("CC" flags), and you're
> >running with "option abortonclose" whic
On Tue, May 27, 2014 at 08:20:07PM +0200, Jakov Sosic wrote:
> On 05/27/2014 08:04 PM, Sasha Pachev wrote:
> >Jakov:
> >
> >There could be multiple reasons. My first thought is to run a network
> >sniffer like tcpdump, capture the relevant traffic, then analyze, and
> >go from there.
>
> Yeah that
On 05/27/2014 08:21 PM, Willy Tarreau wrote:
What is happening here is simple : the client disconnected before the
connection to the server managed to complete ("CC" flags), and you're
running with "option abortonclose" which allows haproxy to kill a pending
connection to the server.
Given how
On 05/27/2014 08:09 PM, Lukas Tribus wrote:
> Are you all your backend up, running and stable? How are your timeouts
configured?
My first server in my backend is down permanently (hw failure) and is
marked as down in haproxy stats page. That shouldn't be a problem?
Other backends seem fine.
Hi Jakov,
On Tue, May 27, 2014 at 07:40:31PM +0200, Jakov Sosic wrote:
> Hi guys,
>
>
> I can see a lot of errors like this in my haproxy log:
>
> May 26 20:57:40 localhost haproxy[9762]: :53644
> [26/May/2014:20:57:40.611] main backend/server03 12/0/-1/-1/12 503 212 -
> - CCVN 148/105/16/6/0
On 05/27/2014 08:04 PM, Sasha Pachev wrote:
Jakov:
There could be multiple reasons. My first thought is to run a network
sniffer like tcpdump, capture the relevant traffic, then analyze, and
go from there.
Yeah that what's I just did, and here are the results:
May 27 20:09:31 localhost hapro
Hi Andy,
On Tue, May 27, 2014 at 06:00:37PM +0100, Andrew Phillips wrote:
> Something I overlooked replying to on this thread;
>
> > BTW, I remember you said that you fixed the busy loop by disabling the
> > FD in the speculative event cache, but do you remember how you re-enable
> > it ? Eg, if
Hi Jakov,
> I can see a lot of errors like this in my haproxy log:
>
> May 26 20:57:40 localhost haproxy[9762]: :53644
> [26/May/2014:20:57:40.611] main backend/server03 12/0/-1/-1/12 503 212 -
> - CCVN 148/105/16/6/0 0/0 {www.example.org|Mozilla/5.0 (Windows NT 6.2;
> WOW64) Appl|http://www.exam
Jakov:
There could be multiple reasons. My first thought is to run a network
sniffer like tcpdump, capture the relevant traffic, then analyze, and
go from there.
On Tue, May 27, 2014 at 11:40 AM, Jakov Sosic wrote:
> Hi guys,
>
>
> I can see a lot of errors like this in my haproxy log:
>
> May 2
Hi guys,
I can see a lot of errors like this in my haproxy log:
May 26 20:57:40 localhost haproxy[9762]: :53644
[26/May/2014:20:57:40.611] main backend/server03 12/0/-1/-1/12 503 212 -
- CCVN 148/105/16/6/0 0/0 {www.example.org|Mozilla/5.0 (Windows NT 6.2;
WOW64) Appl|http://www.example.com/
Your email client cannot read this email.
To view it online, please go here:
http://online.marketingbox.ro/mailing/display.php?M=9940176&C=e0442cdcdd93d6960ec7a79157fcfea9&S=115&L=31&N=71
To stop receiving these
emails:http://online.marketingbox.ro/mailing/unsubscribe.php?M=9940176&C=e0442cdcdd9
Something I overlooked replying to on this thread;
> BTW, I remember you said that you fixed the busy loop by disabling the
> FD in the speculative event cache, but do you remember how you re-enable
> it ? Eg, if all other processes have accepted some connections, your
> first process will have to
On Mon, May 26, 2014 at 10:03:41PM -0400, Dan Crosta wrote:
> Thanks, Willy, that makes sense. What settings should we look at
> tuning? We already have backlog set to 32k in the defaults, but with
> fairly low timeouts for connect, queue, and server. Should we try
> setting those timeouts somewhat
Hi Sasha,
On Mon, May 26, 2014 at 12:33:48PM -0600, Sasha Pachev wrote:
> I am attaching a patch that incorporates your revisions.
Thank you, I've applied it now.
Best regards,
Willy
Here some Benchmarks with aes-256-cbc:
##OpenSSL 0.9.8
16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
165967.40k 176138.69k 178376.08k 165082.46k 178232.41k
### OpenSSL 1.0.1 without AES-NI (without kernel extension loaded)
16 bytes 64 bytes256 bytes 1024 byte
On Tue, May 27, 2014 at 11:10 AM, William Attwood
wrote:
> With CPU details, do you know if virtualized CPU's offer this functionality?
> We're running a VMWare ESXi 5.5 installation with Intel Westmere CPU's.
>
> Thank you,
> William Attwood
> System Engineer, Co-Founder
> Open Box I.T. Solutions
Aristedes Maniatis wrote:
On 27/05/2014 6:59pm, Lukas Tribus wrote:
aesni_load="YES" in loader.conf should take care of the AES side of things
As far as I know you don't need to load the AES-NI extension on FreeBSD
anymore, openssl will use acceleration without this statement in
loader.conf
On 27/05/2014 6:59pm, Lukas Tribus wrote:
> Hi,
>
>
>> Without purchasing specific expensive add-on cards [1], is there
>> something specific to some modern CPUs which will accelerate SSL
>> handling in haproxy 1.5?
>>
>> That is, should I be looking for something in a CPU which will
>> improve p
With CPU details, do you know if virtualized CPU's offer this
functionality? We're running a VMWare ESXi 5.5 installation with Intel
Westmere CPU's.
Thank you,
William Attwood
System Engineer, Co-Founder
Open Box I.T. Solutions, LLC
c. 801-634-6479
On Tue, May 27, 2014 at 2:59 AM, Lukas Tribus
Hi,
> Without purchasing specific expensive add-on cards [1], is there
> something specific to some modern CPUs which will accelerate SSL
> handling in haproxy 1.5?
>
> That is, should I be looking for something in a CPU which will
> improve performance considerably? There is an Intel instruction
Hi,
>> Has anyone opened a bug against Chrome for this behavior (did a brief search
>> and didn't see one)? I'd be interested in following it as this behavior will
>> likely have an impact on an upcoming project I've got.
>>
>> -Patrick
>
> Hi Patrick,
>
> yes:
> https://code.google.com/p/chromiu
Hey Ari,
if you use a recent Intel CPU with AES-NI support and OpenSSL 1.0.1,
harware accelereation will be used by default if you're using AES ciphers.
You can benchmark the performance with and without hardware acceleration
using these two commands:
# without acceleration
OPENSSL_ia32cap
On Tue, May 27, 2014 at 9:34 AM, Aristedes Maniatis wrote:
> Without purchasing specific expensive add-on cards [1], is there something
> specific to some modern CPUs which will accelerate SSL handling in haproxy
> 1.5?
>
> That is, should I be looking for something in a CPU which will improve
Without purchasing specific expensive add-on cards [1], is there something
specific to some modern CPUs which will accelerate SSL handling in haproxy 1.5?
That is, should I be looking for something in a CPU which will improve
performance considerably? There is an Intel instruction set called AES
HI All,
I have searched a lot abotu this and it's not clear to me.
De we need to use ACL's in this matter or not. I can make a simple rewrite
but its unclear to me how to use the lookup from a map(file).
Any suggestions ?
Thanks!
Matt
2014-05-26 17:33 GMT+02:00 Matt . :
> Hi Baptiste,
>
>
26 matches
Mail list logo
