3 ms·
It's phrased oddly but what he's saying there in other words is: "I can't use caching for writing to the database". This is of course true but surprising as tha
by bhaak 10y ago
It's phrased oddly but what he's saying there in other words is: "I can't use caching for writing to the database". This is of course true but surprising as that has nothing to do with the problem.
Maybe that's was just his usual approach "if it's too slow, cache it" instead of looking at what makes it slow. As mentioned in the first paragraph, he didn't have to "tackle the really problems[tm]" so far. So he didn't have lots of practise yet.
Although I also agree that with 100+ requests per seconds, the database certainly should not be the problem but you need to get the data to the database in the first place (and that turned out to be the issue).
- smcl 10y agoI can see the logic - if you have a service that only takes GPS co-ordinates and dumps them into a database, and it's underperforming then my first thought would also have been "why is my DB insert slow?" instead of "what part of my service is slow?" (in fact I'd have probably ditched the DB insert and written a console.log() which likely would've turned up the problem). These sort of educated guesses serve me well most of the time and take a short period of time to verify - if the guess is wrong we can look in-depth using whatever tools are available safe in the knowledge that not much time was wasted Speaking of tooling, is there much available for nodejs that would allow this sort of investigation into performance, or debugging line by line?