4 ms·

I’m sure your super awesome programming skills that fix infrastructure and eliminate network I/O are very cool!

by devmor 1y ago

sfn42 1y ago
I'm not claiming to eliminate network transfer times. Sending a web request takes some time. But it doesn't take seconds, it takes anywhere from a few to a few hundred milliseconds, given that the request size is relatively small. If you're sending megabytes or gigabytes then obviously it takes longer. So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc. Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc. We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work. Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds. I hope this gives you a better idea of what I'm saying.
- devmor 1y ago
  I don't really know how else to lead you to understand that when you query a data source you do not have control over, through a network you do not have control over, you cannot make the interface work faster than the response from that data source. No matter how good your programming skills are, your endpoint cannot return data faster than it retrieves it.
  - sfn42 1y ago
    I completely understand that. You just haven't mentioned it until now. You could also look for inefficiencies in the search. Maybe the query is inefficient, maybe you can make use of database functionality such as full-text search and/or indexes etc. If you don't have access to make those changes to the db, you can cache the data in your backend memory, your own DB, Redis or whatever you prefer, so your app can be nice and snappy regardless of how ass your dependency is.

I’m sure your super awesome programming skills that fix infrastructure and eliminate network I/O are very cool!

by devmor 1y ago

I’m sure your super awesome programming skills that fix infrastructure and eliminate network I/O are very cool!

I'm not claiming to eliminate network transfer times. Sending a web request takes some time. But it doesn't take seconds, it takes anywhere from a few to a few hundred milliseconds, given that the request size is relatively small. If you're sending megabytes or gigabytes then obviously it takes longer. So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc. Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc. We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work. Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds. I hope this gives you a better idea of what I'm saying.

devmor 1y ago
I don't really know how else to lead you to understand that when you query a data source you do not have control over, through a network you do not have control over, you cannot make the interface work faster than the response from that data source. No matter how good your programming skills are, your endpoint cannot return data faster than it retrieves it.
- sfn42 1y ago
  I completely understand that. You just haven't mentioned it until now. You could also look for inefficiencies in the search. Maybe the query is inefficient, maybe you can make use of database functionality such as full-text search and/or indexes etc. If you don't have access to make those changes to the db, you can cache the data in your backend memory, your own DB, Redis or whatever you prefer, so your app can be nice and snappy regardless of how ass your dependency is.