Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Keeping MySQL connection parameters in a safe place

by leocharre (Priest)
on Dec 27, 2005 at 19:22 UTC ( [id://519400]=note: print w/replies, xml ) Need Help??


in reply to Keeping MySQL connection parameters in a safe place

Ok this is pretty cool.. I think I need to using something like this. My question.. this hits the disk, so.. performance - If I need to query a table every time a user logs in, etc- this creates an expensive disk operation, right?

If 20 people log in per minute, or if every time a user does something I need to perform some kind of query to the db, then.. won't reading from disk for a db connection sort of slow things?

Maybe I'm missing something here- maybe I should be looking into opening a db connection for a user's session and not closing it somehow ?

  • Comment on Re: Keeping MySQL connection parameters in a safe place

Replies are listed 'Best First'.
Re^2: Keeping MySQL connection parameters in a safe place
by tirwhan (Abbot) on Dec 27, 2005 at 19:42 UTC

    Where do you think your database retrieves its data from, thin air? ;-) No, the db reads its data from disk as well, and that's a much more complicated operation than a simple text file read. Luckily (for both cases) the OS will cache often-accessed data in RAM, and therefore the expensive disk operation turns into a simple memory lookup. Which is why database servers can have too little RAM even if only a small percentage of it is being used by the DB process.


    A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

      Now, if I have a text file with the word 'soup' in it. And I have an infinite loop that makes a system call to a script that reads the content into memory and then exits.. . Are you saying at some point the text file will be coming from memory instead of disk ?!

      What if it's an infinite loop and it's spaced at a random 1 to 10 seconds appart?

        Not only that, but if you have a process that opens the file, performs tr/ua/au/ on the content and writes it back, exits and starts again, then chances are most of these actions will never touch the disk but rather be performed entirely in RAM. Changed content will be written out to disk eventually of course, but that happens largely asynchronously to your activities and it's likely to be at a time when your OS isn't busy with the disk anyway and the disk is in a good state to perform the write. Assuming you're on a decent OS.

        There are a number of parameters which influence how and when this will happen, such as frequency of the read/writes, general memory pressure on the system, disk activity, the filesystem used and also mount options (on *NIX you can mount disks in sync mode which ensures that data is written out to disk almost immediately, this can obviously slow down the system a lot).

        See this text for some more details on how this is done on Linux.


        A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://519400]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-04-24 02:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found