<html><head></head><body class="ApplePlainTextBody" dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><blockquote type="cite">On 28.01.2019, at 01:39, Chris Muller <ma.chris.m@gmail.com> wrote:<br><br>Hi,<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Yes, the SqueakMap server image is one part of the dynamic, but I<br>think another is a bug in the trunk image. I think the reason Tim is<br>not seeing 45 seconds before error is because the timeout setting of<br>the high-up client is not being passed all the way down to the<br>lowest-level layers -- e.g., from HTTPSocket --> WebClient --><br>SocketStream --> Socket. By the time it gets down to Socket which<br>does the actual work, it's operating on its own 30 second timeout.<br></blockquote><br>I would expect subsecond reponse times. 30 seconds is just unacceptably<br>long.<br></blockquote><br>Well, it depends on if, for example, you're in the middle of<br>Antarctica with a slow internet connection in an office with a fast<br>connection. A 30 second timeout is just the maximum amount of time<br>the client will wait for the entire process before presenting a<br>debugger, that's all it can do.<br></blockquote><br>We can be sure that Tim should get subsecond response times instead of<br>timeouts after 30 seconds.<br></blockquote><br>Right, but timeout settings are a necessary tool sometimes, my point<br>was that we should fix client code in trunk to make timeouts work<br>properly.<br><br>Incidentally, 99% of SqueakMap requests ARE subsecond -- just go to<br>map.squeak.org and click around and see. For the remaining 1% that<br>aren't, the issue is known and we're working on a new server to fix<br>that.<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It is a fixed amount of time, I *think* still between 30 and 45<br>seconds, that it takes the SqueakMap server to save its model after an<br></blockquote></blockquote></blockquote></blockquote><br>and so if in the meantime it can simply be made to wait 45s instead of<br>30s, then current SqueakMap will only be that occasional delay at<br>worst, instead of the annoying debugger we currently get.<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">You would save seconds, not milliseconds by not downloading files again.<br></blockquote><br>IIUC, you're saying we would save one hope in the "download" --<br>instead of client <--> alan <--> andreas, it would just be client <--><br>alan. Is that right?<br></blockquote><br>No. If the client doesn't have the mcz in the package cache but nginx has<br>it in its cache, then we save the transfer of data between alan and<br>andreas.<br></blockquote><br>Are alan and andreas co-located?<br></blockquote><br>They're VMs on rackspace. The slowest bandwidth Rackspace has is 200 MBit/s, the fastest 2 GBit/s, i forgot which we have.<br>The network is not the limiting factor here, Squeak is.<br><br><blockquote type="cite"><br><blockquote type="cite">The file doesn't have to be read from the disk either.<br></blockquote><br>I assume you mean "read from disk" on alan? What about after it's<br>cached so many mcz's in RAM that its paging out to swap file? To me,<br>wasing precious RAM (of any server) to cache old MCZ file contents<br>that no one will ever download (because they become old very quickly)<br>feels wasteful. Dragster cars are wasteful too, but yes, they are<br>"faster"... on a dragstrip. :) I guess there'd have to be some kind<br>of application-specific smart management of the cache...<br><br>Levente, what about the trunk directory listing, can it cache that?<br>That is the _#1 thing_ source.squeak.org is accessing and sending back<br>over, and over, and over again -- every time that MC progress box that<br>says, "Updating [repository name]".<br><br><blockquote type="cite">If the client does have the mcz, then we save the complete file transfer.<br><br><blockquote type="cite"><br>I don't know what the speed between alan <---> andreas is, but I doubt<br>it's much slower than client <---> alan in most cases, so the savings<br>would seem to be minimal..?<br></blockquote><br>The image wouldn't have to open a file, read its content from the disk and<br>send that through a socket.<br></blockquote><br>By "the image" I assume you mean the SqueakSource server image. But<br>opening the file takes very little time. Original web-sites were<br>.html files, remember how fast those were? Plus, filesystems "cache"<br>file contents into their own internal caches anyway...<br><br>Yes, it still has to return back through alan but I assume alan does<br>not wait for a "full download" received from andreas before its<br>already pipeing back to the Squeak client. If true, then it seems<br>like it only amounts to saving one hop, which would hardly be<br>noticeable over what we have now.<br><br><blockquote type="cite">Nginx does that thing magnitudes faster than<br>Squeak.<br></blockquote><br>The UX would not be magnitudes faster though, right?<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">That would also let us save bandwidth by not downloading files already<br>sitting in the client's package cache.<br></blockquote><br>How so? Isn't the package-cache checked before hitting the server at<br>all? It certainly should be.<br></blockquote><br>No, it's not. Currently that's not possible, because different files can<br>have the same name. And currently we have no way to tell them apart.<br></blockquote><br>No. No two MCZ's may have the same name, certainly not withiin the<br>same repository, because MCRepository cannot support that. So maybe<br></blockquote><br>Not at the same time, but it's possible, and it just happened recently<br>with Chronology-ul.21.<br>It is perfectly possible that a client has a version in its package cache<br>with the same name as a different version on the server.<br></blockquote><br>But we don't want to restrict what's possible in our software design<br>because of that. That situation is already a headache anyway. Same<br>name theoretically can come only from the same person (if we ensure<br>unique initials) and so this is avoidable / fixable by resaving one of<br>them as a different name...<br><br><blockquote type="cite"><blockquote type="cite">we need project subdirectories under package-cache to properly<br>simulate each cached Repository. I had no idea we were neutering 90%<br>of the benefits of our package-cache because of this too, and just<br>sitting here, I can't help wonder whether this is why MCProxy doesn't<br>work properly either!<br><br>The primary purpose of a cache is to *check it first* to speed up<br>access to something, right? What you say about package-cache sounds<br></blockquote><br>I don't know. It wasn't me who designed it. :)<br></blockquote><br>I meant ANY "cache".<br><br> https://en.wikipedia.org/wiki/Cache_(computing)<br><br>For Monticello, package-cache's other use-case is when an<br>authentication issue occurs when trying to save to a HTTP repository.<br>At that point the Version object with the new ancestry was already<br>constructed in memory, so rather than worry about trying to "undo" all<br>that, it was simpler and better to save it to a package-cache, persist<br>it safely so the client can simply move forward from there (get access<br>to the HTTP and copy it or whatever).<br><br>- Chris<br><br><blockquote type="cite"><blockquote type="cite">really bad we should fix that, not surrender to it.<br></blockquote><br>Yes, that should be fixed, but it needs changes on the server side.<br>What I always had in mind was to extend the repository listing with<br>hashes/uuids so that the client could figure out if it needs to download a<br>specific version. But care must be taken not to break the code for<br>non-ss repositories (e.g. simple directory listings).<br><br>Levente<br><br><blockquote type="cite"><br>- Chris<br></blockquote></blockquote></blockquote><br></body></html>