Performance of demos on sharejs.org

[Stephan Seidt]

Hi,

I'm interested in the operational behavior of ShareJS and what one should be careful about.

So here's a very generic question: Why are the demos on the sharejs.org website sometimes slow?

For example, in the code editor even the initial requests took up to 10 seconds in some cases.

Cheers

Stephan

[David Greisen]

I've found the same thing on my own server, and I traced it back to browserchannel, the default transport layer for sharejs. It takes a minimum of 2 second to perform the initial handshake - never had it take less. I don't know if this is a problem inherent to browserchannel or just of the sharejs's browserchannel implementation, but I was able to solve the problem by switching to sockjs. Handshakes now happen almost instantaneously, even for browser that have to use a fallback transport other than websockets.

[Stephan Seidt]

Not getting the same result. I have:

- sharejs master

- bin/exampleserver

- client and server on same host (localhost)

- demo: code editor

With the above I have no (initial) lag at all (in total <20ms for the first request).

[David Greisen]

But you are seeing the problem on the demo page? I have no idea what could be different.

[Stephan Seidt]

I see the problem on the sharejs.org/code.html demo page but my local one is fine and very fast (using browserchannel).

Also conducting some node client to node server browserchannel tests there's no initial delay at all.

[Hochhaus, Andrew]

On Mon, Nov 26, 2012 at 10:11 AM, David Greisen <dgre...@gmail.com> wrote:
> It takes a minimum of 2 second to perform the initial handshake - never had it take less. I don't know if this is a problem inherent to browserchannel or just of the sharejs's browserchannel implementation, but I was able to solve the problem by switching to sockjs. Handshakes now happen almost instantaneously, even for browser that have to use a fallback transport other than websockets.

BrowserChannel performs a buffered proxy test with a 2 second timeout.
The idea is that the server sends one chunk of '11111' then waits 2
seconds and finally sends a second chunk of '2'. If the client gets
'11111' alone, it continues on immediately knowing that no buffering
proxy exists. However, if the client gets '111112' (after two seconds)
it is behind a buffering proxy. My guess is that David is behind a
buffering proxy but Stephan is not (hence the drastic startup
differences).

http://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol#Buffering_Proxy_Test

-Andy

[Joseph Gentle]

On Tue, Jan 29, 2013 at 8:54 AM, Hochhaus, Andrew
<ahoc...@samegoal.com> wrote:
> On Mon, Nov 26, 2012 at 10:11 AM, David Greisen <dgre...@gmail.com> wrote:
>> It takes a minimum of 2 second to perform the initial handshake - never had it take less. I don't know if this is a problem inherent to browserchannel or just of the sharejs's browserchannel implementation, but I was able to solve the problem by switching to sockjs. Handshakes now happen almost instantaneously, even for browser that have to use a fallback transport other than websockets.
>
> BrowserChannel performs a buffered proxy test with a 2 second timeout.
> The idea is that the server sends one chunk of '11111' then waits 2
> seconds and finally sends a second chunk of '2'. If the client gets
> '11111' alone, it continues on immediately knowing that no buffering
> proxy exists. However, if the client gets '111112' (after two seconds)
> it is behind a buffering proxy. My guess is that David is behind a
> buffering proxy but Stephan is not (hence the drastic startup
> differences).

Quite right. If I connect to http://sharejs.org:8000/, its a fair bit
faster. I think varnish (which ShareJS.org is sitting behind) is
misconfigured, and is buffering that response.

-J

> http://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol#Buffering_Proxy_Test
>
> -Andy
>
> --
> You received this message because you are subscribed to the Google Groups "ShareJS" group.
> To unsubscribe from this group, send email to sharejs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Joseph Gentle]

Yep, its a problem with varnish's configuration. Browserchannel has a test URL which prints '11111' then after 2 seconds '2'. Its used to check for caching proxies, and if it finds one, it activates a fallback connection mode which doesn't reuse HTTP requests. If you access the nodejs process on sharejs.org directly, it works fine: http://sharejs.org:8000/channel/test?VER=8

.... But if you access port 80, it goes through varnish and it buffers up the whole response. This gives you 2 seconds of latency on connect and then activates browserchannel's crappy mode:

http://sharejs.org/channel/test?VER=8

You can see whats happening using netcat. Good:

$ nc sharejs.org 8000

GET /channel/test?VER=8 HTTP/1.1

Host: sharejs.org

HTTP/1.1 200 OK

Content-Type: text/plain

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

X-Content-Type-Options: nosniff

Date: Thu, 21 Feb 2013 19:14:35 GMT

Connection: keep-alive

Transfer-Encoding: chunked

5

11111

1

2

0

^----- Notice its using chunked encoding to send the '11111' first, then the '2' later.

Bad version (via varnish):

$ nc sharejs.org 80

GET /channel/test?VER=8 HTTP/1.1

Host: sharejs.org

HTTP/1.1 200 OK

Content-Type: text/plain

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

X-Content-Type-Options: nosniff

Content-Length: 6

Accept-Ranges: bytes

Date: Thu, 21 Feb 2013 19:14:25 GMT

X-Varnish: 1968686058

Age: 2

Via: 1.1 varnish

Connection: keep-alive

111112

Does anyone know enough about varnish to tell me how to fix this? At the very least, I should mention this on the node-browserchannel readme page.

-J

> To unsubscribe from this group, send email to sharejs+unsubscribe@googlegroups.com.

[Joseph Gentle]

Just as a quick update to this: I've fixed the varnish config on sharejs.org.

In vcl_recv I've put:

    if (req.url ~ "^/channel/bind" || req.url ~ "^/channel/test") {

        return (pipe);

    }

    if (req.request != "GET" && req.request != "HEAD") {

     .... etc.