外贸业务员开发客户神器
大多数外贸业务员有通过GOOGLE搜索客户信息 但能坚持下来并且开发到客户的很少。 原因 1 、效率太低，严重影响业务员积极性。 2、 无法精准搜索到目标客户信息，需要大量时间筛选。 双喜外贸客户搜索与开发系统。通过全球各大搜索引擎，快速搜索全球潜在客户信 息。 内置五重过滤功能，根据您到需要，呈现出精准的信息。 自动一对一发送邮件，每天联系上万目标客户。 软件功能演示：QQ 343086184 邮件请回复到QQ邮箱。 顺祝 商祺 我已邀请您填写表单 无标题表单。 要填写此表单，请访问： https://docs.google.com/forms/d/1yeBVTu1LTZC4SjaM04gyaBPmDf8fRfeafSvrWTQKiq4/viewform
Re: Fix for rare EADDRNOTAVAIL error
Hi Willy, Thank you a lot for detailed answers. Sorry for so long delay, I have to check docs, configurations and logs. 1. There are no TIME_WAIT connections on our server. They may appear for a very short time, but there are no long-waiting ones. So in that our system works good. OK. When you say the server, you mean the machine running haproxy, can you confirm ? Yes. Sorry for inexact name. 3. With my re-connect loop the second try always was successful. Does it mean that without my loop connection retry mechanism will also successfully re-connect and such log errors may be completely ignored? Yes, and you'll have a non-null retry count on the log lines (the value after the connection counts, also the last field of the second block of 5 counters). Checked our logs. Found the next, for example: cat haproxy.log | grep -A 8 Connect() == Feb 18 04:49:43 localhost haproxy[9335]: Connect() failed for backend https: no free ports. Feb 18 04:49:47 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:45.245] httpinternal httpinternal/app_server1 0/0/0/2394/2394 200 269 - - --NI 200/0/0/0/0 0/0 GET /url HTTP/1.1 Feb 18 04:49:49 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:49.486] httpinternal httpinternal/app_server2 0/0/0/46/46 200 269 - - --NI 200/0/0/0/0 0/0 GET /url HTTP/1.1 Feb 18 04:50:10 localhost haproxy[9335]: IP:port [18/Feb/2014:04:50:07.745] httpinternal httpinternal/app_server1 0/0/0/2935/2935 200 269 - - --NI 201/1/1/0/0 0/0 GET /url HTTP/1.1 Feb 18 04:50:10 localhost haproxy[9335]: IP:port [18/Feb/2014:04:50:10.002] httpinternal httpinternal/app_server2 0/0/0/684/684 200 269 - - --NI 200/0/0/0/0 0/0 GET /url HTTP/1.1 Feb 18 04:50:13 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:40.489] https~ https/app_server2 2127/0/9/943/33140 200 836 - - --NI 199/199/199/99/0 0/0 POST /url HTTP/1.1 Feb 18 04:50:13 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:40.487] https~ https/app_server2 2000/0/129/810/33142 200 836 - - --NI 198/198/198/98/0 0/0 POST /url HTTP/1.1 Feb 18 04:50:13 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:40.489] https~ https/app_server2 1999/0/128/955/33140 200 836 - - --NI 197/197/197/97/0 0/0 POST /url HTTP/1.1 Feb 18 04:50:13 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:40.488] https~ https/app_server2 2000/0/128/900/33141 200 836 - - --NI 196/196/196/96/0 0/0 POST /url HTTP/1.1 == cat haproxy.log | grep -v \-\-[NV][NI] [0-9]*/[0-9]*/[0-9]*/[0-9]*/0 == Feb 18 04:49:43 localhost haproxy[9335]: Connect() failed for backend https: no free ports. Feb 18 04:50:18 localhost haproxy[9335]: IP:port [18/Feb/2014:04:49:40.481] https~ https/app_server1 3120/0/1/4262/37675 200 836 - - --NI 22/22/22/22/1 0/0 POST /url HTTP/1.1 == So it seems that error on 04:49:43 was retried and retry is logged on 04:50:18, isn't it? Could you please confirm that above log says that connect was successfully retried after an error? 5. We see Connect() failed...: no free ports. errors 20-70 times per day (depending on server load). Could you imagine any reasons why such errors may occur? haproxy has only about 500-700 open connections, there are no dead ones, all are in ESTABLISHED state. Do you have any listening ports in the same range as the outgoing port range ? It could be one reason for the system occasionally failing to allocate a port. Yes. It seems that it is the reason. Thank you. Alternately, you can use the source parameter either on each server or in the backend to fix a port range. Haproxy will then use an explicit bind. This is normally used when you want to have more than 64k conns on multiple servers. But here you could try this : source 0.0.0.0:32678-61000 Great! As I understand we can set port range to exclude listening ports and so eliminate such errors? Probably it may be a good workaround. Thank you again for the idea. According to your answers I've re-read source code, documentation, reviewed logs and below is my conclusion about our issue. Could you please check it and correct if I'm wrong or miss something. 1. If 'retries' parameter is set to a value higher than 1 then on such connect error haproxy automatically retries connect attempt. 2. Such errors usually mean critical issues with resources, so their logging is very important and so will not be removed. 3. The information that error is successfully resolved can be taken only from 'info' level logging, moreover -- only by indirect way from a periodical statistics. 4. So, conclusion, we can either just ignore such errors in logs or (more preferably) workaround them by using source port range limits to
http responses randomly getting RSTs
Hi, I'm at my wits end and was hoping you had any ideas. We've setup a test environment with haproxy-1.5dev22, with varnish as a backend (and varnish using a webserver as it's backend). I have the same issue with haproxy-1.5dev19. randomly around the website (if I f.ex. reload /user/login url (it's a drupal website)) - the browser requests fails and the browser says 408. the VIP on haproxy is 10.27.121.134 a wireshark of the reponse shows, that the browser suddenly gets a RST - in the middle of a receiving the response. I did a tcpdump on the haproxy, and on the varnish - and the RST was originating from haproxy. The stats counters shows some ereq - which I think is these RSTs: # pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,comp_in,comp_out,comp_byp,comp_rsp, example.dk,FRONTEND,,,0,6,8000,132,129135,357937,0,0,9,OPEN,1,2,00,0,0,170,35,168,10,0,0,,0,27,213,,,0,0,0,0, example.dk-prod,FRONTEND,,,0,0,8000,0,0,0,0,0,0,OPEN,1,4,00,0,0,00,0,0,0,0,0,,0,0,0,,,0,0,0,0, example.dk-prod,web-p02,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,1,1,0,0,0,890,0,,1,4,1,,0,,2,0,,0,L4OK,,2000,0,0,0,0,0,0,00,0, example.dk-prod,web-p03,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,1,1,0,0,0,890,0,,1,4,2,,0,,2,0,,0,L4OK,,2001,0,0,0,0,0,0,00,0, example.dk-prod,web-p04,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,1,1,0,0,0,890,0,,1,4,3,,0,,2,0,,0,L4OK,,2001,0,0,0,0,0,0,00,0, example.dk-prod,BACKEND,0,0,0,0,800,0,0,0,0,0,,0,0,0,0,UP,3,3,0,,0,890,0,,1,4,0,,0,,1,0,,00,0,0,0,0,0,0,0,0,0,0,0, varnish-dmz,varnish01,0,0,0,3,,102,64617,177379,,0,,0,0,0,0,UP,1,1,0,0,0,890,0,,1,5,1,,102,,2,0,,14,L4OK,,2002,0,17,85,0,0,0,00,0, varnish-dmz,varnish02,0,0,0,3,,102,64518,178650,,0,,0,0,0,0,UP,1,1,0,0,0,890,0,,1,5,2,,102,,2,0,,13,L4OK,,2001,0,18,83,1,0,0,00,0, varnish-dmz,BACKEND,0,0,0,6,800,204,129135,356029,0,0,,0,0,0,0,UP,2,2,0,,0,890,0,,1,5,0,,204,,1,0,,270,35,168,1,0,0,0,0,0,0,0,0, I've tried setting option http-server-close and tried option httpclose - and tried without any of them. My config is: global chroot /var/lib/haproxy daemon group haproxy log 127.0.0.1 local0 maxconn 4000 pidfile /var/run/haproxy.pid stats socket /var/lib/haproxy/stats level admin user haproxy defaults log global maxconn 8000 option redispatch retries 3 stats enable option httpclose option http-server-close timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s frontend example.dk bind 10.27.121.134:80 bind 10.27.121.134:443 ssl crt /etc/haproxy/star2.pem ciphers RC4-SHA:AES128-SHA:AES256-SHA mode http balance roundrobin default_backend varnish-dmz option tcplog option accept-invalid-http-request timeout client 30 listen example.dk-prod bind 10.27.121.135:80 bind 10.27.121.135:443 ssl crt /etc/haproxy/wildcard.example.dk.combined.pem ciphers RC4-SHA:AES128-SHA:AES256-SHA mode http balance roundrobin option tcplog server web-p02 10.27.121.245:80 check server web-p03 10.27.121.246:80 check server web-p04 10.27.121.247:80 check backend varnish-dmz balance roundrobin mode http option tcplog server varnish01 10.27.121.240:80 check server varnish02 10.27.121.241:80 check -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
Re: http responses randomly getting RSTs
I enabled stats listener to better get an overview of the numbers.. and it seems there's no ereq.. and haproxy doesn't log anything interesting :( In debug mode I get a LOT.. It seems it's easier to reproduce, if I hit ctrl+f5 (which goes fine) and right after that, press f5 - that gives me the 408. -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
Re: http responses randomly getting RSTs
Enabling debug in config, I only get a more detailed upstart info and a copy of my config in my logs, and then these upon requests: Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58864 [18/Feb/2014:14:46:02.199] example.dk varnish-dmz/varnish01 0/0/1 6315 -- 6/6/0/1/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58860 [18/Feb/2014:14:46:02.199] example.dk varnish-dmz/varnish02 0/0/8 7302 -- 6/6/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58866 [18/Feb/2014:14:46:02.354] example.dk varnish-dmz/varnish01 0/0/1 1812 -- 1/1/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58867 [18/Feb/2014:14:46:02.390] example.dk .dk/NOSRV -1/-1/31 212 cR 0/0/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58868 [18/Feb/2014:14:46:02.429] example.dk varnish-dmz/varnish02 0/0/1 2639 -- 2/2/1/1/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58869 [18/Feb/2014:14:46:02.430] example.dk varnish-dmz/varnish01 0/0/1 1808 -- 2/2/0/1/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58868 [18/Feb/2014:14:46:02.431] example.dk varnish-dmz/varnish02 0/0/16 25620 -- 2/2/1/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58869 [18/Feb/2014:14:46:02.431] example.dk varnish-dmz/varnish01 0/0/16 27614 -- 3/3/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58870 [18/Feb/2014:14:46:02.448] example.dk varnish-dmz/varnish02 0/0/1 826 -- 3/3/0/1/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58870 [18/Feb/2014:14:46:02.449] example.dk varnish-dmz/varnish01 0/1/4 6526 -- 4/4/1/1/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58868 [18/Feb/2014:14:46:02.447] example.dk varnish-dmz/varnish02 0/0/7 3206 -- 5/5/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58869 [18/Feb/2014:14:46:02.448] example.dk varnish-dmz/varnish01 0/0/12 50494 -- 5/5/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58871 [18/Feb/2014:14:46:02.454] example.dk .dk/NOSRV -1/-1/31 212 cR 2/2/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58872 [18/Feb/2014:14:46:02.455] example.dk .dk/NOSRV -1/-1/30 212 cR 1/1/0/0/0 0/0 -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
RE: http responses randomly getting RSTs
Hi, Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58871 [18/Feb/2014:14:46:02.454] example.dk .dk/NOSRV -1/-1/31 212 cR 2/2/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58872 [18/Feb/2014:14:46:02.455] example.dk .dk/NOSRV -1/-1/30 212 cR 1/1/0/0/0 0/0 cR means [1]: The timeout http-request stroke before the client sent a full HTTP request. This is sometimes caused by too large TCP MSS values on the client side for PPPoE networks which cannot transport full-sized packets, or by clients sending requests by hand and not typing fast enough, or forgetting to enter the empty line at the end of the request. The HTTP status code is likely a 408 here. Does your tcpdump confirm this? Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.5
Re: http responses randomly getting RSTs
Lukas Tribus said the following on 02/18/2014 03:43 PM: Hi, Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58871 [18/Feb/2014:14:46:02.454] example.dk .dk/NOSRV -1/-1/31 212 cR 2/2/0/0/0 0/0 Feb 18 14:46:02 localhost haproxy[23414]: 10.46.10.145:58872 [18/Feb/2014:14:46:02.455] example.dk .dk/NOSRV -1/-1/30 212 cR 1/1/0/0/0 0/0 cR means [1]: The timeout http-request stroke before the client sent a full HTTP request. This is sometimes caused by too large TCP MSS values on the client side for PPPoE networks which cannot transport full-sized packets, or by clients sending requests by hand and not typing fast enough, or forgetting to enter the empty line at the end of the request. The HTTP status code is likely a 408 here. Does your tcpdump confirm this? What would I look for in the tcpdump? it's a vmware virtualserver with standard MTU and all.. no PPPoE or anything. I can reproduce it by pressing f5 (a few times in a row) in my browser (firefox) and IE. I cannot reproduce it in chromium. -- Regards, Klavs Klavsen, GSEC - k...@vsen.dk - http://www.vsen.dk - Tlf. 61281200 Those who do not understand Unix are condemned to reinvent it, poorly. --Henry Spencer
RE: http responses randomly getting RSTs
Hi, What would I look for in the tcpdump? Whether or not the browser takes more than 10 seconds to complete the http request, as per your configuration: timeout http-request 10s This is the timeout you are hitting. Also read this [1]. Share your tcpdump capture if it doesn't contain anything proprietary (an tell us which tcp session in the capture failed, according to your log). Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#timeout%20http-request
RE: http responses randomly getting RSTs
Hi, Whether or not the browser takes more than 10 seconds to complete the http request, as per your configuration: timeout http-request 10s it's not even close to 10 seconds.. it happens as soon as I press f5 - randomly. Well, I was assuming this is the issue, since it was the only error from your logs and it seemed to be reoccurring. You did confirmed 408 errors on the client side though, so this is still my best bet. Please provide a non-truncated capture (-s 0) of the session where you see this RST. Filtering on the client IP is probably a good idea to keep the capture limited to your IP (something like tcpdump -ps0 -w haproxy-rstcapture.cap host 1.2.3.4 and tcp port 80 for example). Regards, Lukas
Limpieza profunda de interior de vehículos Dto. 40%
Ofertas de hoy en Mar del Plata precio descuento ahorro $ 329.00 40 % $ 221 40% Dto. Limpieza de interior de vehículos por Proclean Máquinas de última generación Secado rápido deja solo 5% de humedad Sistema de inyección/extracción PROCLEAN limpia, desinfecta y desodoriza alfombras,… seguir leyendo Compartir$329.00 Ver la Oferta precio descuento ahorro $ 175.00 30 % $ 75 30% Dto. Latex interior extra cubritivo Z10 de Sherwin Williams Z10 Interiores Mate es una pintura al látex para interiores formulada bajo las rigurosas normas de Sherwin Williams de excelente… seguir leyendo Compartir$175.00 Ver la Oferta precio descuento ahorro $ 175.00 50 % $ 175 50% Dto. En Mar Del Plata: Acceso a Balneario en Punta Mogotes febrero La oferta incluye: Día de Acceso al Balneario número 1 Portal del Sol en Punta Mogotes: Carpa para 6 personas… seguir leyendo Compartir$175.00 Ver la Oferta precio descuento ahorro $ 138.00 23 % $ 42 23% Dto. Latex interior Alba por 4 Lts 10 Lts o 20Lts Látex de acabado mate para interiores, buen poder cubriente. Muy buena resistencia al uso diario. De fácil aplicación y rápido… seguir leyendo Compartir$138.00 Ver la Oferta Todos los días descuentos en tu ciudad de hasta el 70% en www.atualcanze.com Si tenés cualquier duda o sugerencia llamanos al teléfono fijo (0223) 475-0972 de lunes a viernes de 9 a 14 hs. Si desea Desuscribirse, por favor, envíe un e-mail con el asunto Remover a sopo...@atualcanze.com
Remove specific query string, redirect + preserve other query strings
Hi All,
I have an issue where I need to remove a query string from a url. I can do
this in apache (see example below) but we are trying to move most of our
apache rewrites into haproxy to ease deployments and complexity on each
node.
- Working Apache example (removes page=0):
RewriteCond %{QUERY_STRING} ^page=([0-9]{1})?(.*)$
RewriteRule (.*) $1?%2 [R=301]
Anything.php needs to be really, anything as this could be folder/script or
another query string.
From Url:
http://example.com/anything.php?page=0test=0hello=yes
To Url:
http://example.com/anything.php?test=0hello=yes
Is this possible?
Thanks!
Andrew
