Hi All, This is a strange one. Ages ago we suddenly had NZ visitors complaining about time outs and white screens for our web apps. Noting else was broken except the people across the ditch (and a few other overseas customers). After testing and trying a vast number of things we put up varnish and told them to connect on port :6xxx and hey presto it all went back to normal. We did this for a few months and then decided to move everything on :80 through varnish. The speed improvement is great. Love it. Amazing. And now we have the NZ clients complaining that things are dropping out and whitescreening again. Is there a great firewall of Australia on port 80? How can one service on port :6xxx work flawlessly and then when moved to :80 kill overseas users? Really this is doing my head in. I am faced with changing everything back (and removing varnish and the speed it gives) and getting the NZ folks to use a weird port again. Clues appreciated. Cheers Piers
On 21 November 2014 11:51, Piers Rowan <piers.rowan@recruitonline.com.au> wrote:
Is there a great firewall of Australia on port 80? How can one service on port :6xxx work flawlessly and then when moved to :80 kill overseas users?
The first random thought that enters my head is maybe the visitors are using an ISP that has some sort of transparent proxy that is filtering requests to port 80. No idea if this will explain it or not, just a thought. -- Brian May <brian@microcomaustralia.com.au>
On 21/11/14 13:56, Brian May wrote:
The first random thought that enters my head is maybe the visitors are using an ISP that has some sort of transparent proxy that is filtering requests to port 80.
No idea if this will explain it or not, just a thought.
Thanks Brian, From speaking to the clients and them following up with their ISP's the claim that there is no proxying going on. The issues are also encountered for clients in the UK and on different ISP's in NZ. Here's one site that is behind the varnish cache: http://www.job3rd.com/ It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load. Cheers P
On 21/11/2014 3:03 PM, Piers Rowan wrote:
On 21/11/14 13:56, Brian May wrote:
The first random thought that enters my head is maybe the visitors are using an ISP that has some sort of transparent proxy that is filtering requests to port 80.
No idea if this will explain it or not, just a thought.
Thanks Brian,
From speaking to the clients and them following up with their ISP's the claim that there is no proxying going on.
The issues are also encountered for clients in the UK and on different ISP's in NZ.
Here's one site that is behind the varnish cache:
It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load.
Cheers
P _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Nice and fast from here (internode NBN connection). cheers Brian
Piers Rowan wrote:
On 21/11/14 13:56, Brian May wrote: ............snip
Here's one site that is behind the varnish cache:
It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load. I gave up with it half loaded after 179 seconds.........."one second" ." two seconds". :-] Often my download speed is >= 1MB/s (thats Bytes); SeaMonkey, ISP= iPrimus, North Melbourne
regards Rohan McLeod
On 21 November 2014 15:03, Piers Rowan <piers.rowan@recruitonline.com.au> wrote:
On 21/11/14 13:56, Brian May wrote:
The first random thought that enters my head is maybe the visitors are using an ISP that has some sort of transparent proxy that is filtering requests to port 80.
No idea if this will explain it or not, just a thought.
Thanks Brian,
From speaking to the clients and them following up with their ISP's the claim that there is no proxying going on.
They say that, but if it works differently on port 6000 to port 80, then it sounds awfully likely that there IS something different about the path the traffic takes. Change your web server to support SSL*and then see if the clients who are having trouble can access the SSL version without the same trouble. (As the secured version has to be pass-thrued by transparent proxies or otherwise the cert won't match) -Toby * you can get free SSL certs these days; StartSSL was easy enough for me to use, but there are probably others.
On 21/11/14 15:14, Toby Corkindale wrote:
They say that, but if it works differently on port 6000 to port 80, then it sounds awfully likely that there IS something different about the path the traffic takes.
That's what I was afraid of.
Change your web server to support SSL*and then see if the clients who are having trouble can access the SSL version without the same trouble. (As the secured version has to be pass-thrued by transparent proxies or otherwise the cert won't match)
I did try to get the SSL to terminate at Varnish but it appears I need another SSL capable web server to work with. I will check it out tonight.
-Toby * you can get free SSL certs these days; StartSSL was easy enough for me to use, but there are probably others.
Good to know - appreciated. Thanks for testing it in 3 locations. Cheers P
On 21 November 2014 16:21, Piers Rowan <piers.rowan@recruitonline.com.au> wrote:
Change your web server to support SSL*and then see if the clients who are having trouble can access the SSL version without the same trouble. (As the secured version has to be pass-thrued by transparent proxies or otherwise the cert won't match)
I did try to get the SSL to terminate at Varnish but it appears I need another SSL capable web server to work with. I will check it out tonight.
nginx tends to be the go-to software for this. It'll handle SSL and reverse-proxying, and is reasonably straight-forward to set up. If you're on Ubuntu, add the nginx-stable PPA so as to get a reasonably recent version, rather than the old-stable version that ships by default.
On 21 November 2014 15:03, Piers Rowan <piers.rowan@recruitonline.com.au> wrote:
Here's one site that is behind the varnish cache: http://www.job3rd.com/ It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load.
Loads fast for me, tested via three outbound locations: Melbourne, London and Cairns. T
On 2014-11-21 05:03, Piers Rowan wrote:
Here's one site that is behind the varnish cache:
It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load.
Works fine from Lund, Sweden.
On 21 Nov 2014 15:03, "Piers Rowan" <piers.rowan@recruitonline.com.au> wrote:
It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load.
No problems for me from AARNet, Internode, or Telstra 3G.
I'm in Vic it took <2 seconds to load via bigpond
On 21 Nov 2014 15:03, "Piers Rowan" <piers.rowan@recruitonline.com.au <mailto:piers.rowan@recruitonline.com.au>> wrote:
It comes up quickly for me. (I'm in QLD its in ADE). I would be keen to hear if anyone else finds it laggy or slow to load.
No problems for me from AARNet, Internode, or Telstra 3G.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On 21 Nov 2014 15:03, "Piers Rowan" wrote:
ok from Canberra iinet/internode (chrome, firefox, firefox mobile). firefox from Toronto .ca and Durban .za are ok too. according to traceroute, both the overseas ones are incoming to .au via sjc1.he.net (San Jose I presume, Hi NSA) and then various vocus.net.au starting in Sydney and eventually 20 as9297.adl01.sa.vocus.net.au (119.161.94.66) 926.605 ms 926.588 ms 926.563 ms these last hops are common to them all 21 g0-2.bdr1.dc2.colocity.com (119.252.0.57) 928.787 ms 930.270 ms 928.264 ms 22 g1-1.c45.dc1.colocity.com (119.252.0.94) 929.482 ms 929.225 ms 931.431 ms 23 ge-1-1.dist.dc1.colocity.com (119.252.31.242) 796.185 ms 794.946 ms 796.651 ms 24 www.webgen.com.au (119.252.17.65) 792.222 ms !X 792.740 ms !X 792.718 ms !X if you think it's filtering/broken caching somewhere, then maybe look at where NZ traceroutes diverge from those that work? cheers, robin
Been a while but I used to fix similar issues by manipulating MTU on the problem server Regards Slav ________________________________ From: luv-main on behalf of Robin Humble Sent: Friday, November 21, 2014 5:12:46 PM To: luv-main@luv.asn.au Subject: Re: Varnish :80 New Zealand Apache Problems
On 21 Nov 2014 15:03, "Piers Rowan" wrote:
ok from Canberra iinet/internode (chrome, firefox, firefox mobile). firefox from Toronto .ca and Durban .za are ok too. according to traceroute, both the overseas ones are incoming to .au via sjc1.he.net (San Jose I presume, Hi NSA) and then various vocus.net.au starting in Sydney and eventually 20 as9297.adl01.sa.vocus.net.au (119.161.94.66) 926.605 ms 926.588 ms 926.563 ms these last hops are common to them all 21 g0-2.bdr1.dc2.colocity.com (119.252.0.57) 928.787 ms 930.270 ms 928.264 ms 22 g1-1.c45.dc1.colocity.com (119.252.0.94) 929.482 ms 929.225 ms 931.431 ms 23 ge-1-1.dist.dc1.colocity.com (119.252.31.242) 796.185 ms 794.946 ms 796.651 ms 24 www.webgen.com.au<http://www.webgen.com.au> (119.252.17.65) 792.222 ms !X 792.740 ms !X 792.718 ms !X if you think it's filtering/broken caching somewhere, then maybe look at where NZ traceroutes diverge from those that work? cheers, robin _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.
Is the 6xxx using SSL? That's one possibility. A quick search using "SSL MTU" criterion gives few pointers. Regards Slav ________________________________ From: luv-main on behalf of Piers Rowan Sent: Saturday, November 22, 2014 7:45:42 AM To: luv-main@luv.asn.au Subject: Re: Varnish :80 New Zealand Apache Problems On 22/11/14 08:26, Pidgorny, Slav(GPM) wrote:
Been a while but I used to fix similar issues by manipulating MTU on the problem server
Cheers Slav, Just a follow up - why would MTU have different effects on port :6xxx vs :80? Cheers P _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.
On Fri, 21 Nov 2014 10:51:33 AM Piers Rowan wrote:
Is there a great firewall of Australia on port 80? How can one service on port :6xxx work flawlessly and then when moved to :80 kill overseas users?
I'd suggest using tcptraceroute to see if there are any differences in routing between those two ports - it'll expose transparent proxies too as they need to terminate the connection short of the destination. Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
participants (10)
-
Anders Holmström -
Brian May -
Brian Parish -
Chris Samuel -
Pidgorny, Slav(GPM) -
Piers Rowan -
Robin Humble -
Roger -
Rohan McLeod -
Toby Corkindale