Cómo desarrollar y mantener clientes clave para siempre
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
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
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
требуете осязать мир точно?
Ваша жизнь будет симпатичнее. Ваша жизнь случится насыщеней и любопытней. Вы по-видимому и не подозревали. http://goo.gl/g8Oa9J
RE: set weight bug?
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
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 ?
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 ?
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
