Michele, I read this thread, not sure if it is not already existing... But it start to look like a recipe for speed tuning that could be translate into a web2py slice or blog post :)
Richard On Tue, Apr 17, 2012 at 2:32 PM, Michele Comitini < michele.comit...@gmail.com> wrote: > What I suggest is use nginx + uwsgi or nginx + scgi or nginx + fcgi. > You will notice big reduction in resource consuption compared to > Apache. > Apache can be taken away. By the way you can use any of the above > protocols to do balancing over a pool of machines running web2py and > in front you can put nginx as balancer. > > About caching, what is important is using as much as possible the > *static* dir and have the files underneath served by nginx directly. > You must check that expiration times on static objects are correctly > set. Also use sprites as much as you can. You will enjoy a big > improvement because after downloading the objects the first time a > client browser will make only requests for the dynamically generated > contents. Other objects will be taken by the ondisk cache of the > browser. If the object is expired in browser cache, but the content > not changed on the server, the request will result only in a 304 > answer so little data is exchanged and little computation is required. > > mic > > > Il 17 aprile 2012 19:10, Bruce Wade <bruce.w...@gmail.com> ha scritto: > > Currently I just had 1 server running apache mod_wsgi using the same > > configuration as pyramid. However I just got approved for a few grand a > > month to spend on server resources, so I am looking at load balancers. > And I > > will put nginx in front of apache, and also start using a lot more > caching. > > > > > > On Tue, Apr 17, 2012 at 5:15 AM, Michele Comitini > > <michele.comit...@gmail.com> wrote: > >> > >> One more thing make css and js packed + server side gzipped (nginx and > >> cherokee can do also gzip caching) > >> > >> mic > >> > >> Il 17 aprile 2012 14:12, Michele Comitini <michele.comit...@gmail.com> > >> ha scritto: > >> > If you are on postgreSQL use a process per request setup, you will > >> > have a great benefit. Use cherokee or nginx (with keepalive working) > >> > you will scale smoothly. > >> > > >> > Check that you do as much as possible of a page in a single http > >> > request (i.e. limit ajax load). Use only one cacheable css and limit > >> > the number of scripts or aggregate them in a cacheable file. > >> > Check that everything that is cacheable gets cached indeed (use > >> > firebug or chrome dev tools to find out). > >> > > >> > mic > >> > > >> > > >> > Il 17 aprile 2012 14:07, Michele Comitini <michele.comit...@gmail.com > > > >> > ha scritto: > >> >> What is your architecture? What do you use as frontend http server? > >> >> What protocol: SCGI, UWSGI, FCGI...? > >> >> Are you in a thread per request or process per request setup? > >> >> > >> >> mic > >> >> > >> >> > >> >> Il 17 aprile 2012 08:36, Bruce Wade <bruce.w...@gmail.com> ha > scritto: > >> >>> Yes you are correct plus there was 10,000+ requests a second just > >> >>> hitting > >> >>> the site I think I really need a load balanced. We are getting on > >> >>> average > >> >>> 500-1000 new members a day. > >> >>> > >> >>> On Apr 16, 2012 10:59 PM, "pbreit" <pbreitenb...@gmail.com> wrote: > >> >>>> > >> >>>> Don't forget you probably spent quite a bit if time tuning your > >> >>>> Pyramid > >> >>>> app. > >> >>>> > >> >>>> The best ways to scale are: > >> >>>> 1) Cache > >> >>>> 2) Cache > >> >>>> 3) Cache > >> >>>> > >> >>>> Web2py makes caching queries super easy. > >> >>>> > >> >>>> If you are serving a lot of static assets, check out Cloudflare for > >> >>>> free > >> >>>> CDN. > > > > > > > > > > -- > > -- > > Regards, > > Bruce Wade > > http://ca.linkedin.com/in/brucelwade > > http://www.wadecybertech.com > > http://www.fittraineronline.com - Fitness Personal Trainers Online > > http://www.warplydesigned.com > > >
