No, the disk access won't slow it down. The filesystem basically just provides a namespace for the sockets, so it's at most an initial inode lookup at. And you can get rid of even that potential disk access by putting the socket in a memory based filesystem. Systems like linux even provide abstract unix domain sockets that are anonymous (well they exist in a backing virtual filesystem), and these are nowadays supported in perl.
This kind of disk access isn't something to worry about anyways on busy servers. Due to it being busy, the information will normally be cached in memory, so no actual disk access takes place (well, sometimes for atime updating, but that can be turned off and is usually write-behind anyways).
But if you wanted *extreme* speed, you probably shouldn't have chosen perl in the first place. The processing you'll do will normally swamp this kind of detail. First write a clear well working program, and only when it turns out to be too slow, profile and start optimizing *only* the slow parts. Don't start guessing too early and destroy the cleanness of your program. (to give an order of magnitude, on a somewhat modern processor you should be able to handle a few 1000 protocol roundtrips per second in perl)
In reply to Re^4: Trapping socket error in client when server goes away
by thospel
in thread Trapping socket error in client when server goes away
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |