El Jue 30 Abr 2009 21:39:27 Rom Walton escribió: > The problem with persistent connections is the overall memory consumed in > just maintaining the connection. > > Even if you striped down the scheduler to a self contained daemon you still > will have to deal with the basics of maintaining connection state for which > ever clients are connected and however many connections need to be made to > the database to service queries promptly. > > More memory in the database server will be allocated towards maintaining > the increased number of connections. > > Eventually you'll be buying new machines to run the server farm, not > because the servers couldn't handle it if the connections closed, but > because the connections last so darn long.
Would it be significant compared to all the mysql_store_result calls done by every daemon, usually with a cap of 1000 rows? And with all the arrays of data objects that the new PHP "DB abstraction layer" creates on every query? Primegrid once had a bit of downtime with its validator, and people couldn't see their list of pending credits. The DB code loads every row into an array of objects, then passes it to the presentation code, instead of streaming from the DB. There were so many pending results that pending.php failed with "maximum memory usage reached". Don't turn down ideas in the name of performance until the *current* performance problems (more like "server resource sinks") are fixed. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
