> On 27.01.2019, at 23:18, Chris Muller <ma.chris.m at gmail.com> wrote:
> 
> Hi Levente,
> 
>>> Yes, the SqueakMap server image is one part of the dynamic, but I
>>> think another is a bug in the trunk image.  I think the reason Tim is
>>> not seeing 45 seconds before error is because the timeout setting of
>>> the high-up client is not being passed all the way down to the
>>> lowest-level layers -- e.g., from HTTPSocket --> WebClient -->
>>> SocketStream --> Socket.  By the time it gets down to Socket which
>>> does the actual work, it's operating on its own 30 second timeout.
>> 
>> I would expect subsecond reponse times. 30 seconds is just unacceptably
>> long.
> 
> Well, it depends on if, for example, you're in the middle of
> Antarctica with a slow internet connection in an office with a fast
> connection.  A 30 second timeout is just the maximum amount of time
> the client will wait for the entire process before presenting a
> debugger, that's all it can do.
> 
>>> It is a fixed amount of time, I *think* still between 30 and 45
>>> seconds, that it takes the SqueakMap server to save its model after an
>>> update (e.g., adding a Release, etc.).  It's so long because the
>>> server is running on a very old 3.x image, interpreter VM.  It's
>>> running a HttpView2 app which doesn't even compile in modern Squeak.
>>> That's why it hasn't been brought forward yet, but I am working on a
>>> new API service to replace it with the eventual goal of SqueakMap
>>> being an "App Store" experience, and it will not suffer timeouts.
>>> 
>>>>> but also:
>>>>> - we can cache: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache
>>>>> - we could make alan not even ask ted when we know the answer already.
>>>>> - Attention: we need a lot of information on what is stable and what not to do this.
>>>>> - (its tempting to try, tho)
>>>>> - (we probably want that for squeaksource/source.squeak for the MCZ requests. but we lose the download statistics then…)
>>>> 
>>>> If squeaksource/mc used ETags, then the squeaksource image could simply
>>>> return 304 and let nginx serve the cached mczs while keeping the
>>>> statistics updated.
>>> 
>>> Tim's email was about SqueakMap, not SqueakSource.  SqueakSource
>> 
>> That part of the thread changed direction. It happens sometimes.
>> 
>>> serves the mcz's straight off the hard-drive platter.  We don't need
>>> to trade away download statistics to save a few ms on a mcz request.
>> 
>> Download statistics would stay the same despite being flawed (e.g.
>> you'll download everything multiple times even if those files are sitting
>> in your package cache).
> 
> Not if we fix the package-cache (more about this, below).
> 
>> You would save seconds, not milliseconds by not downloading files again.
> 
> IIUC, you're saying we would save one hope in the "download" --
> instead of client <--> alan <--> andreas, it would just be client <-->
> alan.  Is that right?

Yes.

> 
> I don't know what the speed between alan <---> andreas is, but I doubt
> it's much slower than client <---> alan in most cases, so the savings
> would seem to be minimal..?

No. It is not about bandwidth. Nginx is much faster in serving files than 
(a) squeak/seaside/squeaksource is and 
(b) there is no network/bookkeeping/requesthandling involved when nginx just 
    serves files. and even if there is (eg, w/ x-accel-redirect), nginx ist just
    plain faster.

> 
>>>> That would also let us save bandwidth by not downloading files already
>>>> sitting in the client's package cache.
>>> 
>>> How so?  Isn't the package-cache checked before hitting the server at
>>> all?  It certainly should be.
>> 
>> No, it's not. Currently that's not possible, because different files can
>> have the same name. And currently we have no way to tell them apart.
> 
> No.  No two MCZ's may have the same name, certainly not withiin the
> same repository, because MCRepository cannot support that.  So maybe
> we need project subdirectories under package-cache to properly
> simulate each cached Repository.  I had no idea we were neutering 90%
> of the benefits of our package-cache because of this too, and just
> sitting here, I can't help wonder whether this is why MCProxy doesn't
> work properly either!

That would be only true if we never would rewrite history or move packges from inbox anywhere else…

> 
> The primary purpose of a cache is to *check it first* to speed up
> access to something, right?  What you say about package-cache sounds
> really bad we should fix that, not surrender to it.
> 
> - Chris
>