PDA

View Full Version : Reusing existing MySQL connection (after application was terminated)



durbrak
2nd August 2007, 14:22
Hello,
this might sound strange but I'll try to explain it anyway :)

I have a program that outputs data from my MySQL-database to the console. Every time the program starts it creates a new connection to the database. Creating that connection costs about 20ms on my machine. The problem is, that the program has to exit after it is finished with the outputting (yes, it really has to because it is kinda a plugin for another program which starts my program automatically each time again). While 20ms doesn't sound like alot for a user, it is quite alot to me because I need the program to go as fast as it can on my slow machine :)

Now I thought it would be efficient somehow to create the database connection only once and not close it after the program is finished executing and just reuse the exisiting connection (somehow) in the newly started process.

Well, I have absolutely no clue how to realize that. Maybe someone here has a good idea to implement a good solution (maybe create another program that will be started over and over again by the program (the one I write the plugin for) and simply pass the request along to my actual application (which never closes) and return the output from my program to the program (the one I write the plugin for), lol very confusing but thats the best idea i had so far). Maybe there is a much better way?

jacek
2nd August 2007, 17:12
While 20ms doesn't sound like alot for a user, it is quite alot to me because I need the program to go as fast as it can on my slow machine
Better check how long it takes to create a new process.


Now I thought it would be efficient somehow to create the database connection only once and not close it after the program is finished executing and just reuse the exisiting connection (somehow) in the newly started process.
You can split your application into two parts. A service that works in the background and is always ready to process requests and a client that connects to that service, performs the request and exits.

durbrak
2nd August 2007, 17:45
Better check how long it takes to create a new process.
I know, but I can't avoid that because that is how the program I'm writing this "plugin" for works. Everytime it needs something from my plugin, it starts a new process of my plugin and reads from std my output.
(out of curiosity - how much time does it actually take? :))

About the splitting thingy i thought too. Program A (with the DB) which will run always as a service and will perform the actual calculatings and stuff; and a program B which will be the plugin that will be started every time.
B starts and should send the request to A; A process' the requests and returns the result to B; B returns A's result to the big program i'm writing the plugin for.
The problem here is, that A would require alot of rewrite, because the big program sends its requests through environment variables (getenv()) and stdin and retrieves its results from what i put in std::cout and stdout.
And somehow I think that it's not worth it, because B would have to search for the service each time, connect to it each time, pass along the requests each time, pass along the environment thingies, and A would need a rewrite, and B must again pass along A's result each time to the big program again. I think that would somehow almost cover those 20ms :D

So i just thought there could be a way to "store" the database connection somehow...

jacek
2nd August 2007, 21:28
out of curiosity - how much time does it actually take?
I never had a chance to check that myself, but AFAIR on windows it's quite significant.

Another problem is that every 50 ms or so windows will stop your application and start some other process, so fighting for few ms might not be worth it, unless you go below initial 50 ms.


I think that would somehow almost cover those 20ms :D
Yes, but you might save more on loading all of the Qt DLLs. Of course these are only speculations, you should check everything using profiler.