[Sugar-devel] ASLO

[James Cameron]

On Sun, Jun 01, 2014 at 07:58:17PM +1000, Sam Parkinson wrote:
> I added a blog within the aslo page. What do you think? (here is the
> url if you don't want to scroll up: http://128.199.197.37/ )

I don't think a blog is needed there.

With an empty cache, you're at 739 KB in 27 requests, up from 491 KB
in 23 requests.

With a primed cache, you're at 536 KB in 27 requests, up from 65 KB
in 11 requests.  Maybe you did something to defeat caching.

The images are most of the content, with 403 KB from just one request
to thepatternlibrary.com for al.png.  Perhaps it isn't cached?

On Sat, May 24, 2014 at 09:10:10PM +1000, Sam Parkinson wrote:
> On Thu, May 22, 2014 at 9:44 AM, James Cameron <quozl at laptop.org> wrote:
>     Nor I.  I'm using Firefox, configured to ask before running Flash, and
>     it asks, so that means the page is trying to run something.
> 
> Oops, I accidentally included SocketIO. I have removed it.

Agreed, it is gone.

>     But in a quick search I wasn't able to find what Flash is
>     actually being run.  Maybe it is something in persona.org.  Do
>     you really need to uyse persona.org?
> 
> I think persona is a good login system for users since there is no
> confirm your email stuff.  For me, it provides valid email
> addresses, which is VERY useful.

Okay, but it costs data and time.  In my latest test, it costs at
least 229 KB and 1.7 seconds to load.  While _you_ might want it, do
your needs need to be satisfied regardless of the impact on all your
users?

>     - the slowest response of 1550 ms was from
>       aslo-bot-master.sugarlabs.org, and this large response time
>       persisted on repeated refreshes.
> 
> Oh, that always hit the filesystem. I added a cache now.

Did you measure the time?  It is 1446 ms now, hardly different from
before.  The filesystem is already cached by the operating system, so
adding a cache should have achieved nothing unless you were waiting
for a write to disk to complete.

>     Comparing to activities.sugarlabs.org which, at the moment, has
>     more features:
> 
>     - with an empty cache, a total of 40 requests to just one
>     server, for a total of 381 KB of data,
> 
>     Because the requests were to just one server, the original ASLO
>     loads much much faster.
> 
> But can't the browser only do 2 requests to one server at once?
> Where as it can do async to many servers?

Yes, a browser can do more than one request to one server at a time,
but they usually won't if the server supports pipelining.  They will
send the request within the existing connection.

The browser can't do a new request or a new connection until it has
begun receiving the data that makes the reference to the other server.

Since each new connection (not new request) takes a round trip time to
establish over TCP/IP, it is always best to minimise them.

> Also it is a common standard today (I think) to use a cdn version of
> your scripts.  This means for very common scripts (eg. jquery) it
> will just hit the browser cache.  Also cdns are just faster that 1
> web server.

No, it won't hit the browser cache if the browser hasn't recently used
cdn.  This is one of the reasons why network performance profiling
looks at two different scenarios; empty cache and primed cache.

>     By splitting the requests among multiple servers as you have done:
> 
>     - the browser can't queue multiple GETs in the same HTTP connection,\
> 
> 
> Really?

Yes, really.  As an example using your current design, the browser
can't send a GET for al.png to 128.199.19.37, it has to send it to
thepatternlibrary.com.

>     - the browser must negotiate several new HTTP connections, each
>     with a round trip delay,
> 
> What I could do is combined all the js into 1 file (and same for
> css).  BUT, I'm not sure if just using the cdn version would be
> better; cdns are very fast (and most of the scripts are served
> through cloudflare which has edge cache servers in South America and
> Australia as well as the usual US + Europe + Asia. This is good
> because it is close to sugar users).

When you are not sure, you should test rather than speculate.

I think you might read up on and understand how Sugar Network can be
used.  It brings this content much closer to Sugar users, with much
lower latency.

>     - the web site depends on multiple servers, so the mean time between
>       failure (MTBF) is dramatically reduced.  See [1].
> 
> Well, I think that splitting the servers is actually better.  Some
> things are served by reliable cdns (good).  But separating the
> non-essential bits (comments, recommendations) means that crashes
> there will not effect the essential bits (data.json or
> aslo-bot-master.sugarlabs.org)

You're so brave.  But Sugar Labs has to be careful.  Careful web
design puts the whole content on reliable servers, but as few as
possible, and this results in web sites that continue to function
despite the various temporary problems that occur on the internet.

Such problems are magnified in environments where Sugar is deployed;
saturated networks, low performance, failed server lookups, etc.

>     This is even more important for XO laptops, because they are usually
>     connected over wireless, with varying network latency.
> 
> Ok that is an issue. I could combine files (and put the on
> cloudflare cdn, I think they have a free plan).

The exact implementation is up to you; I couldn't advise you on it.

But eventually, any replacement for ASLO would have to run on the
Sugar Labs hardware we have now.

>     The same can be said of the Search... textbox.
> 
> It looks very obvious on sugar :) Have a look.
> I will make it look more obvious on other stuff too.

If you mean the Sugar search boxes, these have a substantial contrast
against the surrounding frame.

If you mean the web page looks different on Sugar Browse, then you can
ignore my comments about how it looks, because I was using Firefox.

Does it need to look different on Firefox?

-- 
James Cameron
http://quozl.linux.org.au/