On Fri, Oct 9, 2009 at 4:19 PM, Stefan de Konink <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Atif Ghaffar schreef: > >> Stefan, yes I totaly agree with you. > >> I am saying that this is what I was expecting with dbslayer handler, > >> but not getting it. > > > >> The connections from the dbslayer -> database are not staying > persistent. > >> I will do some more tests over the weekend and get back with my > findings. > > Did you expect the actual database connection was stayed up so that you > could set variables and do transactions? > > Stefan, No, I have read the docs and absolutely do not want to do that. just regular simple select from this/that , update, insert, delete. Ok, perhaps some description might help. 1 master DB. (This is the absolute last thing to scale) Stage 1. -------------- 2 application servers. (apache+mod_php+html spaghetti, serving html, css, js, image, php, cofee, soup, etc) scale to 4 spaghetti. scale to 6 spaghetti. Stage 2. -------------- 2. nginx servers to handle everything static and pass everything php via FCGI to php processes running on different machines. 4. php server. All they run is php with FPM (FastCGI Process Manager) Start to looks better but now the code starts to look horrible. All the presentation logic (how to create a select box) and the business logic is in the same place. This was just an isolation step. It did not make anything better, it just shows where the problems are so they could be worked on. Stage 3. -------------- 2 nginx server ... same role, handle static pass all the php stuff to php processing servers. 2 buiness-logc servers (using app-server-in-php using SCGI being served by cherokee-SCGI_handler) http://code.google.com/p/appserver-in-php/ This really remove all the presentation stuff. Even a print "hello" would not be sent to the browser but to the console and forces the developers to think outside the http+browser model. 4 php processors, they now take care of the presentation and talk to the businesslogic system using http -> cherokee-scgi -> app-server So now the situation is that with 20 processes, I have 20 connections open to the database. I want to go to around 200 - 300 processes but no point of keeping 300 connections open to the db. Its not a big deal if we really have to but why do that if it can be avoided. Stage 4. (planning/hoping) -------------- Cherokee-dbslayer comes in. 4-5 servers connecting to the dbserver. This lets the app servers talk to the cherokee dbslayer instead of the dbserver itself. I see it like a pool of 50 connections always open from the dbslayer and the appservers can talk to dbslayers to do the db stuff. This way we can scale each different element separately instead of just throwing resources where we dont know. I hope this explains why I was looking at db_slayer but perhaps I misunderstood how it worked. best regards > > Stefan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEAREKAAYFAkrPRlUACgkQYH1+F2Rqwn1obwCfb2hYucMCbi9P1QrvdlWy5tjI > KA8AniwWBdK5Oz78Qp36gapZ5wFe6fdG > =mtSv > -----END PGP SIGNATURE----- > -- best regards Atif Ghaffar
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
