Cómo desarrollar y mantener clientes clave para siempre

2013-11-06 Thread Paula Maya




Administración de 
Cuentas ClaveBogotá 27 y 28 de Noviembre de 2013Aprenda las técnicas y herramientas que hacen y 
fortalecen una relación fructífera y duradera.
¿Sabe cuánto de las utilidades de su empresa provienen de sólo unos cuantos 
de sus mejores clientes? Enfocarse en estas cuentas es lo más natural;  sin 
embargo, cada vez más, estos clientes exigen trato especial, lo que requiere que 
los ejecutivos de cuenta desarrollen técnicas y habilidades especiales para 
tratar con ellos y capitalizar su importancia estratégica. Para 
ampliar la información y obtener los beneficios de inscripción temprana 
diligencie sin compromiso los siguientes datos: 
-Nombre:-Empresa:-Ciudad:-Teléfono:-E-mail: haproxy@formilux.org"Su 
información jamás será compartida ni comercializada. Garantizamos total 
confidencialidad y privacidad de sus datos"
Centro de atención telefónica: 01 8000 51 30 51, PBX 
(4) 444 09 18 Importante: En cumplimiento con la ley 1581 de 2012, queremos 
comunicarle que si usted no desea recibir la información actualizada con los 
temas más innovadores de nuestra agenda de eventos de capacitación, puede 
des-suscribirse de estas invitaciones respondiendo este correo con el asunto 
quit.La des-suscripción puede tardar de 1 a 5 días. Este correo ha sido 
enviado enviado a: haproxy@formilux.orgEste correo no puede ser considerado intrusivo 
ya que cumple con las políticas antispa m internacionales y locales. 








Re: [PATCH v2] Add ability to select HASH function amongst (SDBM/DJB2/WT6) and optionally apply avalanche

2013-11-06 Thread Bhaskar Maddala
Hello,

  I filled in the test result for the remaining cases. It is the same link
as before [1]. The tests were executed with 3 data sets as follows (a) 10K
requests (includes duplicate host headers) (b) All unique host headers in
1M requests (c) and 250K requests (includes duplicate hosts headers). All
tests used 'balance hdr(Host)' directive in config

  Tests were executed for the following combination (a) One of
SDBM/WT6/DJB2 with (b) One of avalanche enabled/disabled with (c) One of
consistent/map-based.
  SDBM was executed across 3 versions of haproxy (i) 1.4 (ii) 1.5-dev19
(iii) 1.5 with the patches. WT6/DJB2 were only executed with (iii) 1.5 with
the patches.

  The results can be viewed in 3 dimensions, dataset size, algorithms,
avalanche enabled/disabled.

  I will let you draw your own conclusions, these are just me thought. On
this dataset, applying avalanche on SDBM, either consistent or map-based,
makes the distribution worse. DJB2 benefits from having avalanche applied
in all cases.  WT6 benefits from application of avalanche with consistent
hashing, but does not from map-based.

 Let me know in case you want anything additional from me at this time.

Thanks
Bhaskar

[1] http://tinyurl.com/l55zode


On Tue, Nov 5, 2013 at 6:45 PM, Bhaskar Maddala  wrote:

> Hello,
>
>Please find attached the patch with changes we discussed on the email
> thread for the first patch on the same. Test results are at [1]. The only
> variation between this patch and our discussion was on wt6, I have not
> removed it at this time as there are a couple of scenarios when not
> applying avalanche. Overall the result seem to indicate that applying
> avalanche produces worse results for sdbm but better results for djb2.
>
>   On the implementation, I followed the pattern employed for dyn bit on
> the algorithm, this leaves space of 7 hashing algorithm (4 in addition to
> the 3, sdbm/djb2/wt6).
>
>   On the testing, there are some duplicates with the test results I mailed
> in with the first patch, I executed these again as sanity checks to make
> sure everything is complete/correct.  On the tab for 250K requests,
> sections for map-based are incomplete, I will fill these slowly.
>
>   Here is the commit message that best describes the changes
>
> ---
> Summary:
> Avalanche is supported not as a native hashing choice, but a modifier
> on the hashing function.
>
> The default values were selected for backward compatibility with previous
> releases.
>
> The syntax for hash-type config element is
> hash-type {map-based|consistent} [[] avalanche]
>
>
> Examples
>   (default) hash-type map-based
> Map based hashing using sdbm without avalanche
>
>   (default) hash-type consistent
> Consistent hashing using sdbm with avalanche
>
> Additional Examples:
>
>   (a) hash-type map-based sdbm
> Same as default for map-based above
>   (b) hash-type map-based sdbm avalanche
> Map based hashing using sdbm with avalanche
>   (c) hash-type map-based djb2
> Map based hashing using djb2 without avalanche
>   (d) hash-type map-based djb2 avalanche
> Map based hashing using djb2 with avalanche
>   (e) hash-type consistent sdbm avalanche
> Same as default for consistent above
>   (f) hash-type consistent sdbm
> Consistent hashing using sdbm without avalanche
>   (g) hash-type consistent djb2
> Consistent hashing using djb2 without avalanche
>   (h) hash-type consistent djb2 avalanche
> Consistent hashing using djb2 with avalanche
>
> -
>
>   Let me know what you think and any additional changes desired, tho we
> seem to have enabled all configuration options with this change. As next
> steps if you are comfortable with these changes, I would like to get a dev
> version with the patches applied to dark test using our production traffic.
>
>   If you prefer not cutting a dev version at this time, it would be great
> if the git repo were accessible, my git clone hangs without any response,
> looking thru the mailing list, this seems to have happened in the past and
> addressed at the time but might have regressed. Thank you
>
> - Bhaskar
>
>
> [1] http://tinyurl.com/l55zode
>


HAProxy and SSL through and through

2013-11-06 Thread Jacob Gibson
I was happily using HAProxy, until I received word that we need to also
encrypt traffic to the web servers.  So, internet --https--> load balancer
--https--> web servers.  Can I still do this with HAProxy?  We don't need
any Layer 7 rules.  If so, what would the config look like?

We do need the following:

1) HTTPS all the way through
2) Web servers need to see the IP of the user
3) Users need sticky sessions to a web server (where the sticky assignment
counter gets refreshed on each user request)
4) HTTPS Keep-Alive support
5) Mobile and older browser support (I say this because I keep reading this
about SNI, but I don't know if that applies to us)

Would #4 cause problems because HAProxy is a proxy and not a forwarder?

Thanks


требуете осязать мир точно?

2013-11-06 Thread vipspace
Ваша жизнь будет симпатичнее. Ваша жизнь случится насыщеней и любопытней. Вы 
по-видимому и не подозревали. http://goo.gl/g8Oa9J


RE: set weight bug?

2013-11-06 Thread Lukas Tribus
Hi!


> Here is my config http://pastie.org/private/wf0dv30krqpasgmhtdnahw
> (Deleted some servers and two backends for clear config)
>
> I used script to handle servers weight since haproxy-ss-20131031, so I
> never tried previous versions.

Sorry, still can't reproduce.


For problem 1 (after setting weight the unix socket, authentication on the
http stats doesn't work anymore):
can you send us the output of the following curl test, when its working and
another output when its not working:

 curl -v "http://admin:passw0rd@127.0.0.1:11190/ha-stats";> /dev/null


For problem 2 (haproxy crashes after multiple fast "set weight" commands):
please generate a coredump, that will help the developers here understand
what happens:

http://www.mail-archive.com/haproxy@formilux.org/msg09472.html



Regards,

Lukas 


stats: mismatched weight output

2013-11-06 Thread Lukas Tribus
Hi!


While trying to reproduce Igor's problem, I noticed some strange behavior
in the stats output:

A server has an initial weight of 100, and unix socket, html and csv
outputs match. But when I modify the weight (in this case, I set it again
to 100), then the unix socket shows the correct weight of 100, but csv and
html output shows a weight value of 1:

$ echo "get weight b1-n/f1"| socat stdio /tmp/haproxy
100 (initial 100)
$ curl -s "http://admin:passw0rd@10.0.0.55/ha-stats;csv"; | grep "b1-n,f1"
b1-n,f1,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,100,1,0,0,0,389,0,,1,2,1,,0,,2,0,,0,L7OK,200,10,0,0,0,0,0,0,00,0,
$ echo "set weight b1-n/f1 100"| socat stdio /tmp/haproxy
$ echo "get weight b1-n/f1"| socat stdio /tmp/haproxy
100 (initial 100)
$ curl -s "http://admin:passw0rd@10.0.0.55/ha-stats;csv"; | grep "b1-n,f1"
b1-n,f1,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,1,1,0,0,0,406,0,,1,2,1,,0,,2,0,,0,L7OK,200,9,0,0,0,0,0,0,00,0,
$



I understand that the "get weight" command on the unix socket simply uses
sv->uweight (src/dumpstats.c line 1097), while the html/csv output is
using a more complex calculation (src/dumpstats.c line 2303 + line 2388):
 (sv->eweight * px->lbprm.wmult + px->lbprm.wdiv - 1) / px->lbprm.wdiv


It did not look into it any deeper, as that would mean reading code until
I understanding the meaning of those variables :)


Any ideas here?




Thanks,

Lukas 


Does haproxy in transparent mode support FreeBSD's divert mechanism ?

2013-11-06 Thread k simon
Hi, All:
In the past day, I want use pf’s “reply-to” on freebsd to solve ip address 
overlapping problem. But it’s seems that  pf’s “divert-to” and “divert-reply”  
cannot work with haproxy on the same machine.  Does haproxy in transparent mode 
support FreeBSD’s divert mechanism ?


Regards
Simon


Does haproxy in transparent mode support FreeBSD's divert mechanism ?

2013-11-06 Thread k simon
Hi, All:
   In the past day, I want use pf’s “reply-to” on freebsd to solve ip address 
overlapping problem. But it’s seems that  pf’s “divert-to” and “divert-reply”  
cannot work with haproxy on the same machine.  Does haproxy in transparent mode 
support FreeBSD’s divert mechanism ?


Regards
Simon