51–60 of 87 posts
I mean... is it? It feels a _lot_ slower than it used to, especially on slower devices. Possibly that 700kB of random crap is implicated :)
Classic HN. Snarky, condescending and nothing of substance. Reminds me why I visit HN less and less lately.
Earlier quoted context omitted.
Considering the functionality, what would be your limit to keep google from being considered a "huge dog"?
42 links, a text box, vector logo, 20kb and that's generous Autocomplete function, dropdown menu JS, 10kb max Considering this page is viewed by millions, and doesn't even contain the logic to render search results
Conversely, why is Windows search so miserably slow?
If you want to search on file contents, use “agent ransack.
I have a related question. How is instacart so slow? I am usually pretty unbothered by slow load times, but searching for and selecting groceries is a full 10 times slower than any other experience on the internet. Is this a deliberate push to get me to use the mobile app? Some dark pattern thing?
It also looks like they might first do all the work to retrieve all the results for a query. The first request is to an endpoint `search_v3/{term}?cache_key={key}` then subsequent requests are to `asyncresultset_{n}?cache_key={key}` so seems like they might have the result set cached from the first query.
The response to the autocomplete endpoint, which is fast, contains an `elastic_id` so perhaps they do partially use a document store.
[0] - https://stackshare.io/posts/the-tech-behind-instacarts-groce... [1] - https://tech.instacart.com/the-story-behind-an-instacart-ord...
When I think of "fast", I always think of a time I was building a product that required subscribing to Twitter's API to receive updates from specific users. In my testing, I'd set a breakpoint on my server code to see when I'd get the "push" from Twitter's API and would use the Twitter App on my phone to create test tweets. Every single time, I'd create a tweet and my server breakpoint would be hit immediately. Not s…
Am I the only person here who wasn’t thinking about the frontend, but rather all the things that need to happen in the backend to render the search results? To me it feels like an oversight when answering the question “how the hell is Google so fast?” and not digging into how Google is able to return the results to your actual search query in a matter of milliseconds. That, to me, is the real miracle.
Earlier quoted context omitted.
I'm just asking you to do the test, because it was forced on me for 6 months of my life :) Firstly, cr.yp.to is hosted on some really basic consumer grade hardware most likely and has to make an additional hop through Tonga of all places for DNS resolution. Of course, the page size of cr.yp.to is very small and does not involve any other communication with other servers to deliver a request. But Google has x million…
Does using the .to TLD really imply that the request has to make a hop through Tonga? I'm not a DNS expert, but that doesn't sound right. (I ask as the owner of a .so site...)
2000-11-16: The .to administrators destroy yp.to for reasons that have never been explained.
See more here: https://cr.yp.to/serverinfo.html
I have a related question. How is instacart so slow? I am usually pretty unbothered by slow load times, but searching for and selecting groceries is a full 10 times slower than any other experience on the internet. Is this a deliberate push to get me to use the mobile app? Some dark pattern thing?
They should be doing a timed release on that. If you stop entering text for N ms, then go for a result. Otherwise they need to have cached results for a huge number of common combinations of letters, very frequently updated, for every store. It's a resource intensive thing to do well at their scale, for such a seemingly simple feature. If they are in fact caching all of those drop-down search results properly, something is very wrong on serving up the cached content.
And for the full results pages, when you try to load them for a given grocery store - the only answer I can guess for that is again mediocre caching. There usually isn't any other culprit other than that for such simple pages. In an effort to match current inventory, my guess is their caching isn't very good (constantly invalidated or rarely put into cache, so they're doing something that isn't very performant; I'd be astounded if they weren't doing some amount of caching on the results).
You can make Google searches plenty slow if you Google something uncached. I just Googled: the OR google OR a OR badger -the -google -a it took: 5.66 seconds. This is probably cached now so don't try it yourself, replace badger with some other weird word. :)
Probably also the sheer frequency of the terms in the OR don't help. Normally "the" would be treated as a stopword (https://en.wikipedia.org/wiki/Stop_word). But I'm not sure if that logic applies when it appears alone in a sequence of terms (as when it's the child of an OR).
Earlier quoted context omitted.
I'm just asking you to do the test, because it was forced on me for 6 months of my life :) Firstly, cr.yp.to is hosted on some really basic consumer grade hardware most likely and has to make an additional hop through Tonga of all places for DNS resolution. Of course, the page size of cr.yp.to is very small and does not involve any other communication with other servers to deliver a request. But Google has x million…
Does using the .to TLD really imply that the request has to make a hop through Tonga? I'm not a DNS expert, but that doesn't sound right. (I ask as the owner of a .so site...)
DJB uses a custom nameserver for DNS, so only one of the lookups would have to go through Tonga. The web request wouldn't leave the US (assuming that's where you are).
It goes sort of like this:
1. You query 'cr.yp.to' which your DNS server will either have cached, or make a recursive query to '.' (root DNS), then to '.to.' The '.to.' server will have nameserver information for 'yp.to.' which gets queried next.
2. The nameserver for 'yp.to' is looked up. In this case, it's `uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.'
3. The A records for that NS record are '131.193.32.109' and '131.193.32.108', both of which belong to an IPv4 block owned by the University of Illinois at Chicago.
4. Your computer queries the A record(s) for the subdomain, 'cr.yp.to.' from the nameserver for 'yp.to.' which in this case points to the same two IPs as the nameserver.
5. Depending on your OS/Browser, you will make an HTTP or HTTPS connection with that server and begin to download site content.
So, no you don't "make a hop" through Tonga, but the '.to.' nameserver will receive a request (if it's not cached by your resolver) to resolve the 'yp.to.' server.