I know the queries utilize more processing, but the connection itself, does it use more RAM than processing?
feedback
|
|
The "connection itself" will use very little of anything relative to the power of modern machines - it is what you do with the connections that makes a difference. "Queries use more processing" is a misleading simplification. If your queries are well optimised then you will usually find that RAM is key (so the DB server can keep a large working set of data and index pages available for quick searching) followed by I/O bandwidth (so the DB service gets quick responses when it needs to access disk because the data it needs isn't in RAM or when it is writing). After those two then you worry about CPU use as some queries do genuinely need a far amount of CPU umpf to do their work once the data is in RAM to do the work on. There are overheads in creating a connection, hence the standard recommendation to do as much as you can in one connection rather than dropping and recreating it for every query (which is why most SQL libraries implement connection pooling), but this overhead is not usually CPU, memory or I/O related - it is usually a matter of communication latency (handshakes between client and server, requesting and sending authentication details, the DB service talking to other services like LDAP if authentication is done via them, and so forth). | |||||
feedback
|