On Sun, Oct 11, 2009 at 5:20 PM, Stefan de Konink <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Atif Ghaffar schreef: > >> Can I contact you off-list? > > > >> I think we have a misunderstanding on how we interpret persistent > >> connection. > > I think onlist is much better to share information. > ok. I just wanted to avoid discussions if they were off-topic > > >> You are thinking in the terms of > >> one dbslayer -> many db replicas. (so perhaps you mean that the reqest > >> from the slayer will always go to the same replica) > > > >> I am trying the opposite. > >> many dblsayers -> one db. (the reason I want to do it , is that I want > >> to know exactly how many connections will the db handle). > > The key observation is here: > > conn = mysql_real_connect (hdl->conn, > hdl->src_ref->host.buf, > props->user.buf, > props->password.buf, > props->db.buf, > hdl->src_ref->port, > hdl->src_ref->unix_socket.buf, > CLIENT_MULTI_STATEMENTS | > CLIENT_MULTI_RESULTS); > > mysql_real_connect() attempts to establish a connection to a MySQL > database engine running on host. mysql_real_connect() must complete > successfully before you can execute any other API functions that require > a valid MYSQL connection handle structure. > > > In that perspective you are right, for each request a new connection is > made. I wrote a handler that used pooling of connections, but there I > could always trust on the fact that I didn't introduce anything /new/. > We could implement such thing here, but as I explained that has serious > downsides regarding to what is stored for the connection local > transaction wise. > > I like this idea. Can we make it a configuaration option / or a separate handler. It would work in my case for example I will know that there are always max 10/100/1000 connections open to the DB no matter what. Everything else will fail in other layers. This way when I know that I must upgrade the DB to handle 100 instead of 10 connections it could be justified. For example if there is a complain "App is too slow" then instead of throwing hardware on it, we can figure out where it is slowing down. Imagine this. A careless application might use DB for session storage. A DDOS on just that website will bring down the DB. Thats just silly. thanks for your answer and best regards > > Stefan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEAREKAAYFAkrR970ACgkQYH1+F2Rqwn2c9gCbBub60tGmYAQWZexqYfcCgZc4 > 5dUAmwefFX6uj2nx0dcWryxuqnryI5ni > =UHui > -----END PGP SIGNATURE----- > -- best regards Atif Ghaffar
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
