Re^2: DBI and FEDERATED table slowdown
by Marshall (Canon) on Feb 28, 2024 at 07:16 UTC
|
Your estimate for the speed of light is wildly off. The speed of light in a vacuum is 299,792,458 meters per second. The speed within the fiber cable or coax is considerably slower than that. Typical coax might be 66% of vacuum speed.
The time is going to be taken up in the various gateways and routers. Perhaps also in retransmissions. 80ms is so incredibly slow for a remote DB, that this is for sure a major problem. My home PC pings google in 13 ms round trip. A well-configured local LAN is going to be much faster than that. | [reply] |
Re^2: DBI and FEDERATED table slowdown
by hippo (Archbishop) on Feb 28, 2024 at 10:49 UTC
|
The speed of light is .3km/sec
I think you are confusing the speed of light with the speed of sound (in air at sea level). 0.3km/s is Mach 1.
so in 80ms, you should be able to do a round trip of 24km.
Even if it were 0.3km/s, in 80ms it would only go 24m, not 24km. Fortunately, light speed is much, much faster than that at 2.99x108m/s. This is how I can get round-trip pings across the Atlantic Ocean in 80ms and how I know it is a rubbish ping time for a LAN.
The point about using DBI->trace is well made, though. I'd also add that a check of the slow query log might be instructive.
| [reply] |
Re^2: DBI and FEDERATED table slowdown
by talexb (Chancellor) on Feb 28, 2024 at 14:52 UTC
|
Jeepers. That will teach me not to post just before bed. I meant to say .3Mkm/sec, you folks are 100% right.
Anyway. It's the next morning, and now I've had my coffee. Looking forward to hearing what trace turns up.
Alex / talexb / Toronto
Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.
| [reply] [d/l] |
|
PMFJI, but .3 Mkm/sec? ITYM .3 Gm/sec - it's Gigameters, just like it's Gigabytes instead of Megakilobytes ;-)
| [reply] |
|
Well, you were not totally wrong, you just referenced the wrong set of dimensions. 300m/s is about right for the speed of light on Terry Pratchett's Discworld, due to the high intensity of its magic field ;-)
Do you currently live in Ankh-Morpork and access PerlMonks through our Clacks/L-Space gateway?
| [reply] |
|
I can't believe this devolved into a physics discussion but everyone gets a ++ vote for their kind assistance!
| [reply] |
Re^2: DBI and FEDERATED table slowdown (time travel ;)
by LanX (Saint) on Feb 28, 2024 at 10:40 UTC
|
> The speed of light is .3km/sec
That's rather the speed of sound and would allow to time travel with supersonic planes.
Hmm... OTOH it's true that the Concorde was capable to arrive before it left. ;)
Updates: added links and amended title | [reply] |
Re^2: DBI and FEDERATED table slowdown
by misterperl (Friar) on Feb 28, 2024 at 16:20 UTC
|
TY Monks, appreciate the thoughts.
On our network, 80ms is, I should say, RELATIVELY fast. But I experimented a bit and you're totally correct- some nodes are sub 1ms. VERY interesting. I'm opening a ticket for our networking crew; I want <1ms I like your idea.
I'll try that trace also- very useful idea.
| [reply] |
|
On our network, 80ms is, I should say, RELATIVELY fast.
Tear it down and rebuild it from scratch.
Ping from home to one of the servers at home is less than 1 ms. Ping to the office firewall is 16 ms (13 hops on the way, 40 km street distance). I've just logged in via VPN to the office network, and I get a constant ping of 16 ms to a random server in the office. I also pinged another system connected via VPN over LTE to the office network to get 52 ms ping time (another 15 km street distance away).
80 ms in a LAN is impressively slow. It sounds like some firewall or router in between your machine and the other machine that is very overloaded and/or very misconfigured. Or you have a severe cabling problem.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
some firewall or router in between your machine and the other machine that is very overloaded and/or very misconfigured.
Time for a "war story" about missing communication between departments.
In my first job, there were two IT departments for historic reasons. The bigger one took care of what you would expect from an IT department. Wiring, power, cooling, fileservers, mailservers, print servers, printers, computers, data links between the offices. I worked for the smaller IT department, formally a part of the knowledge management department. We had our own servers, a database, a few webservers, and a load balancer for a document management system a.k.a. intranet, plus some smaller servers for data research.
One day, our intranet servers were moved from a dark corner in the old office building to a small datacenter in the new office building, together with all other servers. The "wiring IT" people did a good job, after the expected downtime, everything just worked smoothly. A few weeks later, people complained that they could not download Powerpoint presentations from the intranet. All other file formats were ok. Uploads were ok. But you could not download any powerpoint file.
What do you think when you hear that story from a user? Right, "layer 8 problem". Too stupid to download a file from a webserver. But it was really the problem. It seemed like the document management software had a severe problem with downloading Powerpoint files. We could upload Powerpoint files, they appeared in the shared filesystem of the webservers as expected, no bits harmed. We could remotely login to one webserver and download powerpoints from localhost just fine. We had several people search for a problem for almost the entire day, digging even deep into the progam code of the document management, searching for a place were Powerpoint files were handled in a different way than other files. We did not find a single location, of course.
"Oh yes, we have installed content filtering firewalls between the servers and the corporate network to improve server security" said one of the "wiring IT" department, who happended to come into our office room for a different reason. "So our servers become secure if you prevent that users DOWNLOAD potentially malicious files from the server that your F---ING firewall did NOT prevent from being UPLOADED to the servers in the first place? What did you smoke? And why the hell did you hide that information from us? Our servers are hardened, they form an isolated network and expose only HTTP and an API port to the corporate network. How do you expect an unidirectional content filter on only the HTTP port to improve security?"
I don't remember the answers any more, but they were on the level of "Um, yes, but our boss ..." The boss that could hardly tell the difference between a mouse and a rack server had decided to spend a lot of money on useless firewalls. I also don't remember if the firewalls were removed or just had their content filter disabled and thus only prevented access to TCP and UDP ports that were never open on the intranet servers.
A lot of money was burned, but money was no problem during the time of the dot-com-bubble. And we actually had a lot of fun digging though the software and network layers almost all the way down to the bare copper wire while searching for the problem.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
On our network, 80ms is, I should say, RELATIVELY fast. But I experimented a bit and you're totally correct- some nodes are sub 1ms.
Yeah, 80ms is a little beefy. I just tried pinging my client (he's about 10km away, still inside Toronto) and got 16-27ms. Then I tried pinging my own server (with pair.com, same place that hosts this site) and got a much more consistent 17-21ms -- and that's all the way down in Pittsburgh, PA, about 50x further.
Let us know how it all turns out. :)
Alex / talexb / Toronto
Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.
| [reply] |