Re: [ANNOUNCE] haproxy-1.6-dev2

2015-06-18 Thread Baptiste
On Wed, Jun 17, 2015 at 5:08 PM, Willy Tarreau  wrote:
> Hi all,
>
> the impatient readers among you will have noticed that it's been almost 3
> weeks since I sent the e-mail announcing the imminent release of 1.6-dev2.
> That end of merge window has been a nightmare and is not finished, but I
> thought it would be wise to issue dev2 anyway so that people can test the
> stuff that has been merged anyway. Lesson learned, for 1.7 we'll have a
> much shorter merge window so that people don't have enough time to push
> that much stuff at the last minute :-)
>
> To be honnest, I'm far from being satisfied with this version. It's as huge
> as dev1 (344 commits) despite some things still being pending. Also noticed
> quite a number of areas that need to be fixed / cleaned up etc. So at least
> the feature freeze is a good thing.
>
> Reading the changelog since 1.6-dev1, in no particular order, I've found :
>
>   - DNS-based server name resolution : haproxy is now able to periodically
> ask a set of resolvers for the IP address of some servers and to update
> them without restarting. This will make life much easier for people
> running in AWS where IP address change randomly. Some more stuff was
> planned for this such as marking the server as unresolvable if resolving
> fails, but we found that people would probably like to have a configurable
> behaviour. Feedback on this is desired and will drive the next steps.
>
>   - peers protocol v2 : haproxy 1.6 and 1.5 will not be able to synchronize
> their stick tables but on the other hand the new protocol is much better
> and more extensible. First it uses a single connection regardless of the
> number of tables to synchronize. Second it will support synchronizing
> much more than just stick tables. For now it replicates all stick-tables
> contents (including gpc, etc...). This allows reloads to keep entries,
> rates, etc... as well as to pass them to a backup node in case of a
> switchover. It's very likely that during 1.7 development we'll further
> extend the amount of information that can be exchanged.
>
>   - peers support nbproc > 1 as long as they're referenced by a single 
> process,
> and peers sections can be disabled (useful for debugging).
>
>   - config : removed a few deprecated keywords (eg: "reqsetbe"). I wanted to
> remove "block" as well, and appsession. On the first one I'm not sure,
> on the second one only Aleks (the author of the feature) provided some
> feedback and agreed it was probably time for it to go. Expect that we'd
> get rid of them soon if nobody objects.
>
>   - pattern cache : a small lru cache applies to pattern matching when it
> runs from a list (eg: case insensitive string match, regex, etc). This
> can significantly speed up host header matching or regex matching
> against a huge list.
>
>   - support for stateless zip compression with libslz : this doesn't waste
> memory anymore and compresses about 3 times faster than zlib, at a lower
> compression ratio.
>
>   - support for session/transaction/request/response variables : using the
> "set-var" action in {tcp,http}-{request-response} rulesets, it's possible
> to assign the result of a sample expression to a variable allocated on the
> fly and which lasts for all the session, the transaction or just the
> ephemeral processing being done on the request or response. This makes
> it possible to keep copies of certain request information and reuse them
> in the response for example. Some work is still pending on this part,
> in particular the ability to use variables with in all arithmetic
> converters which currently only take a constant.
>
>   - support for declared captures : sometimes it's desired to capture in
> the backend or response path but that was not possible since only the
> frontend can assign a capture slot. The solution consists in making
> it possible to declare a capture slot in the frontend for later use.
>
>   - servers: in addition to DNS, it's possible to change a server's IP address
> from the CLI.
>
>   - ssl: it's now possible to forge SSL certs on the fly. That's convenient
> when haproxy has to be deployed in front of proxies which already work
> like this.
>
>   - device identification : two companies, 51Degrees and DeviceAtlas,
> provided patches to add support for their respective libs. We're
> starting to see some demand for such features due to the abundance
> of smartphones, tablets and I don't-know-what, and both libs come
> with a free device database, so it seems to be the right timing.
> The README was updated for both, there you'll find how to build with
> either solution (or both, I checked and they don't break each other).
> It would be interesting to get feedback on these features, especially
> from people who already have access to the full databases and who 

Super high flux output and high luminance led floodlight

2015-06-18 Thread kathy

  
  
Hello, 
 

  200W IP65 Mean well led high bay  
  
50W led high bay Mean Well driver 43$usd   
  100W led high bay Mean Well driver 72$usd  
  200W led high bay Mean Well driver 148$usd 
   
  We supply led lamp with high quality and competitive price. Hope to cooperate with you.
   
  Best Regards 
  -- 
  Kathy Wu 
  Skype: kathystar11 
  JIN WANG Optoelectronics Co., Limited 
  T: 0086 0755 33165048 |

  

  


Re: TiO2 for paint industry

2015-06-18 Thread Sinotechem
Dear Purchase Manager,
 
Good day!
 
Glad to know you are in the market of chemical raw material. We are Sinotec 
Industrial Group Co.,Ltd, a leading chemical supplier from China. Below is our 
main products list:


1. Titanium Dioxide Anatase / Rutile
2. Zinc Oxide
3. Iron Oxide series
4. Lithopone
5. Pentaerythritol
6. Petroleum Resin


 
Please inform us your specific interests, so that we can send you our detailed 
specification along with the best quotation. Thanks!
 
You are cordially invited to visit our company at your convenience, and we 
await your favorable reply.
 
Sincerely,
Taurin Lee
Manager of International Business Dept 
 

SINOTEC INDUSTRIAL GROUP CO.,LTD
(ISO 9001:2000 Certified)
No.38,Dongfeng Rd., Zhengzhou City PR. China 45
Tel: +86-371-60392052 Fax: +86-371-63726368
E-mail: exp...@sinotechem.com, sinot...@gmail.com
*

Odd SSL performance

2015-06-18 Thread Phil Daws
Hello all:

we are rolling out a new system and are testing the SSL performance with some 
strange results.  This is all being performed on a cloud hypervisor instance 
with the following:

HA-Proxy version 1.5.11 2015/01/31
8GM RAM / 8 CPUs

when we run 'ab' with nbproc set to '1' we see the following:

ab -n 4 -c 2000 https://localhost/status
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 4000 requests
Completed 8000 requests
Completed 12000 requests
Completed 16000 requests
Completed 2 requests
Completed 24000 requests
Completed 28000 requests
Completed 32000 requests
Completed 36000 requests
Completed 4 requests
Finished 4 requests


Server Software:nginx
Server Hostname:localhost
Server Port:443
SSL/TLS Protocol:   TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:  /status
Document Length:16 bytes

Concurrency Level:  2000
Time taken for tests:   101.824 seconds
Complete requests:  4
Failed requests:0
Total transferred:  1740 bytes
HTML transferred:   64 bytes
Requests per second:392.83 [#/sec] (mean)
Time per request:   5091.206 [ms] (mean)
Time per request:   2.546 [ms] (mean, across all concurrent requests)
Transfer rate:  166.88 [Kbytes/sec] received

Now the documentation does say the one should not need to raise nbproc as it 
can make debugging difficult, but to see what would happen we gave it a try:

ab -n 4 -c 2000 https://localhost/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 4000 requests
Completed 8000 requests
Completed 12000 requests
Completed 16000 requests
Completed 2 requests
Completed 24000 requests
Completed 28000 requests
Completed 32000 requests
Completed 36000 requests
Completed 4 requests
Finished 4 requests


Server Software:nginx
Server Hostname:localhost
Server Port:443
SSL/TLS Protocol:   TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:  /
Document Length:0 bytes

Concurrency Level:  2000
Time taken for tests:   45.011 seconds
Complete requests:  4
Failed requests:0
Total transferred:  888 bytes
HTML transferred:   0 bytes
Requests per second:888.67 [#/sec] (mean)
Time per request:   2250.558 [ms] (mean)
Time per request:   1.125 [ms] (mean, across all concurrent requests)
Transfer rate:  192.66 [Kbytes/sec] received

so that is certainly better, but now look what happens if we use purely HTTP:

ab -n 4 -c 2000 http://localhost/status
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 4000 requests
Completed 8000 requests
Completed 12000 requests
Completed 16000 requests
Completed 2 requests
Completed 24000 requests
Completed 28000 requests
Completed 32000 requests
Completed 36000 requests
Completed 4 requests
Finished 4 requests


Server Software:nginx
Server Hostname:localhost
Server Port:80

Document Path:  /status
Document Length:16 bytes

Concurrency Level:  2000
Time taken for tests:   7.152 seconds
Complete requests:  4
Failed requests:0
Total transferred:  1740 bytes
HTML transferred:   64 bytes
Requests per second:5592.99 [#/sec] (mean)
Time per request:   357.591 [ms] (mean)
Time per request:   0.179 [ms] (mean, across all concurrent requests)
Transfer rate:  2375.93 [Kbytes/sec] received

Have tried adding the option prefer-last-server but that did not make a great 
deal of difference.  Any thoughts please as to what could be wrong ?

Thanks, Phil


(null)



RE: Odd SSL performance

2015-06-18 Thread Lukas Tribus
Hi Phil,


> Hello all:
>
> we are rolling out a new system and are testing the SSL performance with
> some strange results. This is all being performed on a cloud hypervisor
> instance with the following:

You are saying nginx listens on 443 (SSL) and 80, and you connect to those
ports directly from ab. Where in that picture is haproxy?



> Have tried adding the option prefer-last-server but that did not make a
> great deal of difference. Any thoughts please as to what could be wrong ?

Without keepalive it won't make any difference. Enable keepalive with ab (-k).



Lukas

  


Re: Odd SSL performance

2015-06-18 Thread Phil Daws
Hello Lukas:

Path is as follows:

Internet -> HAProxy [Frontend:443 -> Backend:80] -> 6 x NGINX

Yeah, unfortunately due to the application behind NGINX our benchmarking has to 
be without keep-alives :(

Thanks, Phil

- On 18 Jun, 2015, at 13:38, Lukas Tribus luky...@hotmail.com wrote:

> Hi Phil,
> 
> 
>> Hello all:
>>
>> we are rolling out a new system and are testing the SSL performance with
>> some strange results. This is all being performed on a cloud hypervisor
>> instance with the following:
> 
> You are saying nginx listens on 443 (SSL) and 80, and you connect to those
> ports directly from ab. Where in that picture is haproxy?
> 
> 
> 
>> Have tried adding the option prefer-last-server but that did not make a
>> great deal of difference. Any thoughts please as to what could be wrong ?
> 
> Without keepalive it won't make any difference. Enable keepalive with ab (-k).
> 
> 
> 
> Lukas

(null)



Re: Odd SSL performance

2015-06-18 Thread Baptiste
Phil,

First, use '-k' option on ab to keep connections alive on ab side.

>From a pure benchamrk point of view, using the loopback is useless!
Furthermore if all VMs are hosted on the same hypervisor.
You won't be able to get any accurate conclusion from your test,
because the injector VM is impacting the HAProxy VM, which migh be
mutually impacted the server VMs...

Baptiste


On Thu, Jun 18, 2015 at 2:41 PM, Phil Daws  wrote:
> Hello Lukas:
>
> Path is as follows:
>
> Internet -> HAProxy [Frontend:443 -> Backend:80] -> 6 x NGINX
>
> Yeah, unfortunately due to the application behind NGINX our benchmarking has 
> to be without keep-alives :(
>
> Thanks, Phil
>
> - On 18 Jun, 2015, at 13:38, Lukas Tribus luky...@hotmail.com wrote:
>
>> Hi Phil,
>>
>>
>>> Hello all:
>>>
>>> we are rolling out a new system and are testing the SSL performance with
>>> some strange results. This is all being performed on a cloud hypervisor
>>> instance with the following:
>>
>> You are saying nginx listens on 443 (SSL) and 80, and you connect to those
>> ports directly from ab. Where in that picture is haproxy?
>>
>>
>>
>>> Have tried adding the option prefer-last-server but that did not make a
>>> great deal of difference. Any thoughts please as to what could be wrong ?
>>
>> Without keepalive it won't make any difference. Enable keepalive with ab 
>> (-k).
>>
>>
>>
>> Lukas
>
> (null)
>



Re: Odd SSL performance

2015-06-18 Thread Phil Daws
Hello Baptiste:

we were seeing lower tps from a remote system to the front-end LB hence trying 
to exclude client side issues by using the LB interface.  Yes, when we use 
'-k', we do see a huge difference but its interesting that we pretty much 
always get 390 tps for a single core, and when we go to nbproc 2 then 780.

Appreciate the input Baptiste & Lukas.

Thanks, Phil.

- On 18 Jun, 2015, at 14:15, Baptiste bed...@gmail.com wrote:

> Phil,
> 
> First, use '-k' option on ab to keep connections alive on ab side.
> 
> From a pure benchamrk point of view, using the loopback is useless!
> Furthermore if all VMs are hosted on the same hypervisor.
> You won't be able to get any accurate conclusion from your test,
> because the injector VM is impacting the HAProxy VM, which migh be
> mutually impacted the server VMs...
> 
> Baptiste
> 
> 
> On Thu, Jun 18, 2015 at 2:41 PM, Phil Daws  wrote:
>> Hello Lukas:
>>
>> Path is as follows:
>>
>> Internet -> HAProxy [Frontend:443 -> Backend:80] -> 6 x NGINX
>>
>> Yeah, unfortunately due to the application behind NGINX our benchmarking has 
>> to
>> be without keep-alives :(
>>
>> Thanks, Phil
>>
>> - On 18 Jun, 2015, at 13:38, Lukas Tribus luky...@hotmail.com wrote:
>>
>>> Hi Phil,
>>>
>>>
 Hello all:

 we are rolling out a new system and are testing the SSL performance with
 some strange results. This is all being performed on a cloud hypervisor
 instance with the following:
>>>
>>> You are saying nginx listens on 443 (SSL) and 80, and you connect to those
>>> ports directly from ab. Where in that picture is haproxy?
>>>
>>>
>>>
 Have tried adding the option prefer-last-server but that did not make a
 great deal of difference. Any thoughts please as to what could be wrong ?
>>>
>>> Without keepalive it won't make any difference. Enable keepalive with ab 
>>> (-k).
>>>
>>>
>>>
>>> Lukas
>>
>> (null)

(null)



Re: Odd SSL performance

2015-06-18 Thread Baptiste
Phil,

without -k, HAProxy spends its time to compute TLS keys.
Can you run 'openssl speed rsa2048' and report here the number?
My guess is that it shouldn't be too far from 400 :)

Baptiste


On Thu, Jun 18, 2015 at 3:20 PM, Phil Daws  wrote:
> Hello Baptiste:
>
> we were seeing lower tps from a remote system to the front-end LB hence 
> trying to exclude client side issues by using the LB interface.  Yes, when we 
> use '-k', we do see a huge difference but its interesting that we pretty much 
> always get 390 tps for a single core, and when we go to nbproc 2 then 780.
>
> Appreciate the input Baptiste & Lukas.
>
> Thanks, Phil.
>
> - On 18 Jun, 2015, at 14:15, Baptiste bed...@gmail.com wrote:
>
>> Phil,
>>
>> First, use '-k' option on ab to keep connections alive on ab side.
>>
>> From a pure benchamrk point of view, using the loopback is useless!
>> Furthermore if all VMs are hosted on the same hypervisor.
>> You won't be able to get any accurate conclusion from your test,
>> because the injector VM is impacting the HAProxy VM, which migh be
>> mutually impacted the server VMs...
>>
>> Baptiste
>>
>>
>> On Thu, Jun 18, 2015 at 2:41 PM, Phil Daws  wrote:
>>> Hello Lukas:
>>>
>>> Path is as follows:
>>>
>>> Internet -> HAProxy [Frontend:443 -> Backend:80] -> 6 x NGINX
>>>
>>> Yeah, unfortunately due to the application behind NGINX our benchmarking 
>>> has to
>>> be without keep-alives :(
>>>
>>> Thanks, Phil
>>>
>>> - On 18 Jun, 2015, at 13:38, Lukas Tribus luky...@hotmail.com wrote:
>>>
 Hi Phil,


> Hello all:
>
> we are rolling out a new system and are testing the SSL performance with
> some strange results. This is all being performed on a cloud hypervisor
> instance with the following:

 You are saying nginx listens on 443 (SSL) and 80, and you connect to those
 ports directly from ab. Where in that picture is haproxy?



> Have tried adding the option prefer-last-server but that did not make a
> great deal of difference. Any thoughts please as to what could be wrong ?

 Without keepalive it won't make any difference. Enable keepalive with ab 
 (-k).



 Lukas
>>>
>>> (null)
>
> (null)
>



Re: Odd SSL performance

2015-06-18 Thread Phil Daws
Baptiste,

as requested:

openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 1189 2048 bit private RSA's in 10.00s
Doing 2048 bit public rsa's for 10s: 50993 2048 bit public RSA's in 10.00s
OpenSSL 0.9.8w 23 Apr 2012
built on: Mon Feb 17 16:11:28 PST 2014
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) 
idea(int) blowfish(ptr2) 
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -fPIC -DPIC -O2 -DNDEBUG -Wl,-z,noexecstack -Wa,--noexecstack 
-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
  signverifysign/s verify/s
rsa 2048 bits 0.008410s 0.000196s118.9   5099.3

we were concerned by using '-k' it would invalidate the results whether that is 
a founded concern ?

Thanks, Phil


- On 18 Jun, 2015, at 14:26, Baptiste bed...@gmail.com wrote:

> Phil,
> 
> without -k, HAProxy spends its time to compute TLS keys.
> Can you run 'openssl speed rsa2048' and report here the number?
> My guess is that it shouldn't be too far from 400 :)
> 
> Baptiste
> 
> 
> On Thu, Jun 18, 2015 at 3:20 PM, Phil Daws  wrote:
>> Hello Baptiste:
>>
>> we were seeing lower tps from a remote system to the front-end LB hence 
>> trying
>> to exclude client side issues by using the LB interface.  Yes, when we use
>> '-k', we do see a huge difference but its interesting that we pretty much
>> always get 390 tps for a single core, and when we go to nbproc 2 then 780.
>>
>> Appreciate the input Baptiste & Lukas.
>>
>> Thanks, Phil.
>>
>> - On 18 Jun, 2015, at 14:15, Baptiste bed...@gmail.com wrote:
>>
>>> Phil,
>>>
>>> First, use '-k' option on ab to keep connections alive on ab side.
>>>
>>> From a pure benchamrk point of view, using the loopback is useless!
>>> Furthermore if all VMs are hosted on the same hypervisor.
>>> You won't be able to get any accurate conclusion from your test,
>>> because the injector VM is impacting the HAProxy VM, which migh be
>>> mutually impacted the server VMs...
>>>
>>> Baptiste
>>>
>>>
>>> On Thu, Jun 18, 2015 at 2:41 PM, Phil Daws  wrote:
 Hello Lukas:

 Path is as follows:

 Internet -> HAProxy [Frontend:443 -> Backend:80] -> 6 x NGINX

 Yeah, unfortunately due to the application behind NGINX our benchmarking 
 has to
 be without keep-alives :(

 Thanks, Phil

 - On 18 Jun, 2015, at 13:38, Lukas Tribus luky...@hotmail.com wrote:

> Hi Phil,
>
>
>> Hello all:
>>
>> we are rolling out a new system and are testing the SSL performance with
>> some strange results. This is all being performed on a cloud hypervisor
>> instance with the following:
>
> You are saying nginx listens on 443 (SSL) and 80, and you connect to those
> ports directly from ab. Where in that picture is haproxy?
>
>
>
>> Have tried adding the option prefer-last-server but that did not make a
>> great deal of difference. Any thoughts please as to what could be wrong ?
>
> Without keepalive it won't make any difference. Enable keepalive with ab 
> (-k).
>
>
>
> Lukas

 (null)
>>
>> (null)

(null)



[SPAM] *Traductions et interprètes de qualité en toutes langues...

2015-06-18 Thread Aurelien SUPOT A.Text Work
Si vous ne visualisez pas correctement l’e-mail, cliquez ici

Bonjour,
 
Je me permets de vous contacter afin de vous proposer nos services de traduction
et d'interprétation professionnelle.
 
Notre agence, basée en France, vous propose:
 
- Un gestionnaire de projet dédié à votre entreprise
- La garantie du respect de la confidentialité de vos documents à traduire.
- Une qualité de traduction irréprochable dans tous les secteurs
d'activité, quelles que soient les combinaisons linguistiques.
- Une réactivité sans égale
 
Quelques références: Disney nature, L'Oréal Luxe, Bourbon, La
Méridionale, Dailymotion, Saint Gobain, Audemars PIGUET, Pierre Hermé,
Airbusiness Academy, Blanchefontaine SA, C-discount, Gretz Communication,
Luminox, Hugo Boss, Axa groupe, International Labour Office (BIT), CNRS, LA
Recherche Magazine, Puy du Fou International, WWF…
 
N'attendez plus pour nous consulter, je suis à votre entière disposition,
 
Bien cordialement
 
Aurelien SUPOT - Developpement A.Text Work
Tel: +33442933429
 
A titre informatif, au cas ou vous auriez également des besoins en
interprétation, je vous transmets  7 liens vers les vidéos des derniers
évènements interprétés par notre agence.
 
PriceMinister

Conseil Général du Loiret

Université du Mans et de Sheffield

Salon international REALNEWTECH

interpretation simultanée Naos group

Price Minister 2 - Pierre Kosciusko-Morizet

Interprétation simultanée pour le point presse ITER

Si vous ne désirez plus recevoir notre lettre d'information, cliquez ici



Delaying requests with Lua

2015-06-18 Thread bjun...@gmail.com
Hi,

i want to delay specific requests and i want to have a random delay
for every request (for example in a range from 1000ms - 2000ms)


As an ugly hack, you can use the following (with a static value):


 tcp-request inspect-delay 2000ms
 tcp-request content accept if WAIT_END


I think i can achieve random delays with Lua. Does anyone have a
example how this can be realized with Lua ?



Thanks in advance !



---
Bjoern



Location of log file of haproxy

2015-06-18 Thread Ajay Kumar
Hi,

I am using HAProxy in smartOS VM of Joyent but failed to trace of its log
file. I explored in internet too but not found any more than following but
then not found folder /etc/rsyslog.d/ in the smartOS.

http://kvz.io/blog/2010/08/11/haproxy-logging/

https://www.percona.com/blog/2014/10/03/haproxy-give-me-some-logs-on-centos-6-5/
I am looking for following help,
1. where is log file of HAProxy
2. how could get the log to my specific log file other than syslog(which
has been mentioned many places in internet)

Regards,
Ajay


Re: Delaying requests with Lua

2015-06-18 Thread Thierry FOURNIER
Hi,

You can do this with Lua. Its very easy.

First, you create a lua file containing the following code. The name of
this Lua file is "file.lua".

   function delay_request(txn)
  core.msleep(1000 + txn.f.rand(1000))
   end

Second, you configura haproxy for loading ths file. In the global
section:

   lua-load file.lua

In your frontend (or backend)

   http-request lua delay_request if { ... your condition ... }

Note that I didn't test this configuration, I'm just giving the main
lines. Please share your results, it's maybe interesting for everyone.

Thierry



On Thu, 18 Jun 2015 17:55:31 +0200
"bjun...@gmail.com"  wrote:

> Hi,
> 
> i want to delay specific requests and i want to have a random delay
> for every request (for example in a range from 1000ms - 2000ms)
> 
> 
> As an ugly hack, you can use the following (with a static value):
> 
> 
>  tcp-request inspect-delay 2000ms
>  tcp-request content accept if WAIT_END
> 
> 
> I think i can achieve random delays with Lua. Does anyone have a
> example how this can be realized with Lua ?
> 
> 
> 
> Thanks in advance !
> 
> 
> 
> ---
> Bjoern
> 



Re: Delaying requests with Lua

2015-06-18 Thread PiBa-NL

Thing to check, what happens to concurrent connection requests?
My guess is with 10 concurrent requests it might take up to 20 
seconds(worst case for 10 connections) for some requests instead of the 
expected max 2..


Thierry FOURNIER schreef op 18-6-2015 om 19:35:

Hi,

You can do this with Lua. Its very easy.

First, you create a lua file containing the following code. The name of
this Lua file is "file.lua".

function delay_request(txn)
   core.msleep(1000 + txn.f.rand(1000))
end

Second, you configura haproxy for loading ths file. In the global
section:

lua-load file.lua

In your frontend (or backend)

http-request lua delay_request if { ... your condition ... }

Note that I didn't test this configuration, I'm just giving the main
lines. Please share your results, it's maybe interesting for everyone.

Thierry



On Thu, 18 Jun 2015 17:55:31 +0200
"bjun...@gmail.com"  wrote:


Hi,

i want to delay specific requests and i want to have a random delay
for every request (for example in a range from 1000ms - 2000ms)


As an ugly hack, you can use the following (with a static value):


  tcp-request inspect-delay 2000ms
  tcp-request content accept if WAIT_END


I think i can achieve random delays with Lua. Does anyone have a
example how this can be realized with Lua ?



Thanks in advance !



---
Bjoern






Re: Delaying requests with Lua

2015-06-18 Thread Thierry
On Thu, 18 Jun 2015 20:27:07 +0200
PiBa-NL  wrote:

> Thing to check, what happens to concurrent connection requests?
> My guess is with 10 concurrent requests it might take up to 20 
> seconds(worst case for 10 connections) for some requests instead of the 
> expected max 2..

Note that we don't use the sleep from the standard Lua API, but the
sleep from the HAProxy Lua API.

The Lua sleep is not a real sleep. It have the behavior of a sleep only
in the Lua code. Is real behavior, is to block the request, set a task
timeour and give back the hand to the HAProxy scheduler.

So, during the sleep, HAProxy is not blocked an continue to process
other connections. Same bahavior for the TCP access; it seeme to be
blocked in the lua code, but HAProxy is not blocked. 

> 
> Thierry FOURNIER schreef op 18-6-2015 om 19:35:
> > Hi,
> >
> > You can do this with Lua. Its very easy.
> >
> > First, you create a lua file containing the following code. The name of
> > this Lua file is "file.lua".
> >
> > function delay_request(txn)
> >core.msleep(1000 + txn.f.rand(1000))
> > end
> >
> > Second, you configura haproxy for loading ths file. In the global
> > section:
> >
> > lua-load file.lua
> >
> > In your frontend (or backend)
> >
> > http-request lua delay_request if { ... your condition ... }
> >
> > Note that I didn't test this configuration, I'm just giving the main
> > lines. Please share your results, it's maybe interesting for everyone.
> >
> > Thierry
> >
> >
> >
> > On Thu, 18 Jun 2015 17:55:31 +0200
> > "bjun...@gmail.com"  wrote:
> >
> >> Hi,
> >>
> >> i want to delay specific requests and i want to have a random delay
> >> for every request (for example in a range from 1000ms - 2000ms)
> >>
> >>
> >> As an ugly hack, you can use the following (with a static value):
> >>
> >>
> >>   tcp-request inspect-delay 2000ms
> >>   tcp-request content accept if WAIT_END
> >>
> >>
> >> I think i can achieve random delays with Lua. Does anyone have a
> >> example how this can be realized with Lua ?
> >>
> >>
> >>
> >> Thanks in advance !
> >>
> >>
> >>
> >> ---
> >> Bjoern
> >>
> 
> 



Re: Delaying requests with Lua

2015-06-18 Thread PiBa-NL
Ok i didn't realize the msleep to be coming from haproxy itself the 
'core.' should have made me think twice before sending that mail.
Thanks for clearing it up, of course still actual results from Bjoern 
will be interesting to hear a well :).


Thierry schreef op 18-6-2015 om 21:12:

On Thu, 18 Jun 2015 20:27:07 +0200
PiBa-NL  wrote:


Thing to check, what happens to concurrent connection requests?
My guess is with 10 concurrent requests it might take up to 20
seconds(worst case for 10 connections) for some requests instead of the
expected max 2..

Note that we don't use the sleep from the standard Lua API, but the
sleep from the HAProxy Lua API.

The Lua sleep is not a real sleep. It have the behavior of a sleep only
in the Lua code. Is real behavior, is to block the request, set a task
timeour and give back the hand to the HAProxy scheduler.

So, during the sleep, HAProxy is not blocked an continue to process
other connections. Same bahavior for the TCP access; it seeme to be
blocked in the lua code, but HAProxy is not blocked.


Thierry FOURNIER schreef op 18-6-2015 om 19:35:

Hi,

You can do this with Lua. Its very easy.

First, you create a lua file containing the following code. The name of
this Lua file is "file.lua".

 function delay_request(txn)
core.msleep(1000 + txn.f.rand(1000))
 end

Second, you configura haproxy for loading ths file. In the global
section:

 lua-load file.lua

In your frontend (or backend)

 http-request lua delay_request if { ... your condition ... }

Note that I didn't test this configuration, I'm just giving the main
lines. Please share your results, it's maybe interesting for everyone.

Thierry



On Thu, 18 Jun 2015 17:55:31 +0200
"bjun...@gmail.com"  wrote:


Hi,

i want to delay specific requests and i want to have a random delay
for every request (for example in a range from 1000ms - 2000ms)


As an ugly hack, you can use the following (with a static value):


   tcp-request inspect-delay 2000ms
   tcp-request content accept if WAIT_END


I think i can achieve random delays with Lua. Does anyone have a
example how this can be realized with Lua ?



Thanks in advance !



---
Bjoern








Re: Location of log file of haproxy

2015-06-18 Thread Baptiste
On Thu, Jun 18, 2015 at 7:17 PM, Ajay Kumar  wrote:
> Hi,
>
> I am using HAProxy in smartOS VM of Joyent but failed to trace of its log
> file. I explored in internet too but not found any more than following but
> then not found folder /etc/rsyslog.d/ in the smartOS.
>
> http://kvz.io/blog/2010/08/11/haproxy-logging/
>
> https://www.percona.com/blog/2014/10/03/haproxy-give-me-some-logs-on-centos-6-5/
>
> I am looking for following help,
> 1. where is log file of HAProxy
> 2. how could get the log to my specific log file other than syslog(which has
> been mentioned many places in internet)
>
> Regards,
> Ajay
>
>

Hi Ajay,

HAProxy sends logs to a syslog server.
So first, ensure your syslog server and HAProxy are propertly configured.
Then, reading your syslog configuration will tell you where the files could be.

Baptiste



Re: LB as a first row of defence against DDoS

2015-06-18 Thread Shawn Heisey
On 6/17/2015 9:29 PM, Krishna Kumar (Engineering) wrote:
> Referring to Baptiste's excellent blog on "Use a lb as a first row of
> defense
> against DDoS" @
> 
> http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos/
> 
> I am not able to find a follow up, if it was written, on combining
> configuration
> examples to improve protection. Is there either another article explaining
> how to combine the configuration settings to protect against multiple
> types of
> DoS attacks, else, how would one do this?

We have a very good query here.

I would like to see an example config that combines all of these
techniques together in the same config that has (as an example) 10 front
ends and 30 back ends, rather than seeing each technique in isolation on
a very limited config.  Looking at the examples, I can't see how to
combine multiple techniques, especially if I want to apply it to a large
config.

Thanks,
Shawn




Raw materials of TiO2 for Paint and Coating

2015-06-18 Thread Sinotechem
Dear Sir or Madam,
 
Greeting!
 
Thank you very much for making time to see my email. This is Taurin, from 
SINOTEC INDUSTRIAL GROUP CO.,LTD, we are a professional and leading Chemicals 
manufacturer for Paint & Coating industry in China, since 1994.

Our core products for the industry:
 
1. Titanium Dioxide Anatase / Rutile
2. Zinc Oxide
3. Iron Oxide series
4. Lithopone
5. Pentaerythritol
6. Petroleum Resin


Should any of these items be of interest to you, please let us know. We will be 
happy to give you a quotation upon receipt of your detailed requirements.

 

Awaiting your reply in the earliest, thanks!

Regards,
Taurin Lee

SINOTEC INDUSTRIAL GROUP CO., LTD
ADD: No.38,Dongfeng Rd., Zhengzhou City PR. China 45
Tel: +86-371-60392052  Fax: +86-371-63726368

Jusqu’au 28 juin, découvrez des offres qui vous ressemblent

2015-06-18 Thread VINCI Immobilier via VisiteOnline
Title: MAILING
  Si ce message ne s'affiche pas correctement, visualisez la version en ligne.













  


  

  

On a tous des envies d'immobilier, et vous ?
  


  

  


J'achète mon 1er
appartement
je veux être gagnant


  


On revend
pour acheter
en toute sérénité

  

Du 28 mai au 28 juin
Découvrez les offres qui vous ressemblent*
  


• Pas de cumul entre mon actuel loyer et mon crédit Immobilier*
  • Prise en charge des intérêts 
intercalaires(2)*
  • Les avantages du Prêt à 
Taux Zéro 2015(1)



• Prise en charges des Intérêts 
Intercalaires et Relais(2)*
• Estimation gratuite et en temps réelle de votre bien à la vente*
• Frais de déménagement offerts*

  


  

  









  


  


  




(1) Offre soumise à conditions. Sous réserve d’acceptation de votre dossier par l’établissement bancaire prêteur. Le Prêt à Taux Zéro Renforcé (PTZ+) instaure un prêt ne portant pas intérêts octroyé aux personnes physiques par les établissements de crédit, qui est destiné à financer la première accession à la propriété. Sous réserve d’acceptation du dossier par un organisme bancaire, cette aide est accordée aux personnes n’ayant pas été propriétaire de leur résidence principale au cours des deux dernières années précédant l’émission de l’offre de prêt. Sous réserves de respecter les conditions fixées aux articles L. 31-10-2 à L. 31-10-12 du Code de la Construction et de l’Habitation. Le montant du prêt sera fonction du coût d’acquisition ou de construction du bien immobilier financé, du nombre de personnes destinées à occuper le logement à titre de résidence principale, de l’ensemble des ressources des personnes susmentionnées, du caractère neuf ou ancien du bien immobilier financé ou encore de la performance énergétique de ce dernier. Les conditions d’octroi du PTZ+ sont disponibles sur simple demande. Ce dispositif est soumis aux conditions de l’article 90 de la loi n °2010-1657 du 29 décembre 2010 modifiée par l’article 59 de la loi n°2014-1654 du 29 décembre 2014.

(2) Offre soumise à conditions. Sous réserve d’acceptation de votre dossier par l’établissement bancaire prêteur.

* Offres soumises à conditions et non cumulables avec d’autres offres en cours ou à venir, valables dans la limite des stocks disponibles pour toute signature d’un contrat de réservation entre le 28 mai et le 15 juillet 2015 et sous conditions d’une réitération de l’acte notarié avant le 31 octobre 2015. Détail des offres et des conditions sur le site : signatures-vinci-immobilier.com. VINCI Immobilier Promotion - RCS Nanterre 339 788 309. Les appartements sont vendus et livrés non aménagés et non meublés, illustrations d’ambiance, non contractuelles. Crédit photo : Graphic Obsession. Conception : Sakara.fr - mai 2015.

Conformément à la loi n° 78-17 du 6 janvier 1978, relative à l’Informatique, aux Fichiers et aux Libertés, vous disposez d’un droit d’accès et de rectification des données à caractère personnel vous concernant et faisant l’objet de traitements sous la responsabilité du RSI.


  
Vous recevez cet email car vous vous êtes inscrits sur Cap decision Immobilier.Conformément à la Loi Informatique et Libertés, vous disposez d'un droit d'accès et de rectification et d'opposition aux données personnelles vous concernant.Afin de l'exercer, cliquez sur le lien de désabonnement suivant : cliquez ici.La base Expli'site a été déclarée à la CNIL sous le N°747587 
Vous utilisez un logiciel de messagerie configuré en mode texte ? Désabonnez-vous en copiant le lien ci-dessous dans votre navigateur : 
http://clap40.neolane.net/nms/jsp/webForm.jsp?fo=FRM365&id=RCoYnbaBh2Mm0nJPgajsQ32%2BxOl%2BCUB1ExJCVCACAA%3D%3D
  









Lua testcase.. some 'random' data returned when loading a image.. 1.6dev2

2015-06-18 Thread PiBa-NL

Hi guys,

I'm sure i am abusing lua for completely wrong thing here.
But i do not understand why the result isn't at least consistent..

Ive got a Pinguïns.jpg of 759kB (Default Windows 7 example image)..
And have the configuration listed below.
When requesting the image from a browser the top of the image looks 
normal, but further down it starts morphing, or becomes complete garbage..
Increasing bufsize to 30 makes the image show normal when reading 
and writing the whole image in 1 variable.. Though the buffer is still 
less than half of the image size.?.


What im wondering though is how can it be that the results with smaller 
bufsizes vary..?? Is it overflowing some memory? With 1.6dev1 it would 
crash after a few requests, dev2 seems to have fixed that.. Though the 
random behavior is still strange.. I would expect every time the same 
image is send it to be cut short at buffsize, or perhaps just work if 
lua might use its own memory buffers not limited to haproxy's buffsize?


Is it a bug? Or just a wrong lua script?
Should files / sockets be closed by the script? I get an error if i 
do..(attempt to use a closed file)


global
#tune.bufsize 30
tune.lua.session-timeout  10
tune.lua.task-timeout 10
lua-load /var/etc/haproxy/hello_world.lua
listen proxy
bind :10001
tcp-request content lua hello_image

function hello_image(txn)
txn.res:send("HTTP/1.1 200 OK\n\n")
f = io.open("/var/etc/haproxy/Penguins.jpg", "rb")
local block = 5000
while true do
local bytes = f:read(block)
if not bytes then break end
txn.res:send(bytes)
--core.msleep(25);   ## changes behavior to be somewhat more 
succesfull..

end
txn:close()
--f:close()   ## [ALERT] 168/232309 (74397) : Lua function 
'hello_image': runtime error: /var/etc/haproxy/hello_world.lua:8: 
attempt to use a closed file.

end

root@OPNsense:/usr/ports/net/haproxy-devel # haproxy -vv
HA-Proxy version 1.6-dev2-ad90f0d 2015/06/17
Copyright 2000-2015 Willy Tarreau 

Build options :
  TARGET  = freebsd
  CPU = generic
  CC  = cc
  CFLAGS  = -O2 -pipe -fstack-protector -fno-strict-aliasing 
-DFREEBSD_PORTS
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 
USE_STATIC_PCRE=1 USE_PCRE_JIT=1


Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Built with OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015
Running on OpenSSL version : OpenSSL 1.0.2b 11 Jun 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with Lua version : Lua 5.3.0
Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY

Available polling systems :
 kqueue : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use kqueue.





Re: http-server-close when a request timeouts after a success HAProxy does not send 504

2015-06-18 Thread Brendan Hubble
Hi Lukas,

Sorry for the misundering. I beleive it is a keep-alive session as the requests 
go one after each other.

When testing with cURL we where using the line as followed. (Address is 
differnt from previous pastebin due to I am testing in VMs)

curl http://172.20.30.167/Sloth/do?t=1000  
http://172.20.30.167/do?t=1

Logs and HAProxy configuration are as followed:

 *   HAProxy Config: https://cloud.openmailbox.org/index.php/s/xvWStS7g1kWZhxX
 *   Frontend pcap: https://cloud.openmailbox.org/index.php/s/8xVOVTV2rlFXSOE
 *   HAProxy Log: https://cloud.openmailbox.org/index.php/s/6dBysTBCgOU440s
 *   Backend pcap: https://cloud.openmailbox.org/index.php/s/Q7fpSzcwzhv1diA

Regards,

Brendan Hubble


From: Lukas Tribus
Sent: Thursday, 18 June 2015 3:12AM
To: Brendan Hubble, Haproxy
Subject: RE: http-server-close when a request timeouts after a success HAProxy 
does not send 504


Hi Brendan,




Hi I am having an issue with HAProxy in http-server-close mode, when more
then one request is sent in a stream and one timeouts after a success it
re-sends that request. On the second request HAProxy send the 504 and the
request is not resent again.


I'm sorry, I don't really get what you are saying. Are you firing 2 simultaneous
requests in a pipelined HTTP session? Or are those 2 consecutive request in
a keep-alived session?





Here is the wireshark logs detailing the events I am seeing.


Yeah we gotta need the full pcap to take a look at the content. Also, please
provide front and backend traffic and the output from the haproxy (http) log.


Regards,

Lukas






30w rgb outer door led floodlight

2015-06-18 Thread kathy

  
  
Hello,
 
Hot sales outdoor 100w COB led floodlight 
 

  LED HIGH BAY LIGHTING 30W led high bay 25$usd each pcs100W led high bay 45$usd each pcs150W led high bay only 58$usd each pcsLED FLOOD LIGHTING 10W only 3.3$usd each pcs50W only 12.5$usd each pcs80W only 22$usd each pcs 
   
  We supply led lamp with high quality and competitive price. Hope to cooperate with you.
   
  Best Regards 
  -- 
  Kathy Wu 
  Skype: kathystar11 
  JIN WANG Optoelectronics Co., Limited 
  T: 0086 0755 33165048  
   
   

  


Spam

2015-06-18 Thread Roger Sikorski
Hello,

It is possibly to stop the spam which arrives here in the mailing list often?

Greetings
Roger

Roger Sikorski

Auszubildender Fachinformatiker Systemintegration

R&R Ice Cream Deutschland GmbH

Eduard Pestel Str. 15

49080 Osnabrück





 Fax: +49 541  301


www.rr-icecream.eu

roger.sikor...@de.rr-icecream.eu



Handelsregister Amtsgericht Osnabrück HRB 17067 Sitz der Gesellschaft: 
Osnabrück Ident Nr. DE 117657534 Geschäftsführer: Dr. Ibrahim Najafi, Dr. 
Gotthard Kirchner
P Before you print think about the ENVIRONMENT



This e-mail has been scanned for viruses by R&R Ice Cream.
The service is powered by MessageLabs.