generally any db interaction takes some time that is the "predominant share" of the response time, so usually you start from there. if you don't have an iper-complicated logic in the controller, the "usual suspects" come in handy: - pre-compile app - use session.forget if you want concurrent requests (e.g., lot of ajax) - use cache wisely (can definitely be the most "speedup-thingy" to do) - tune the webserver accordingly to the stack you're using - move models to modules whenever possible - etc that are all more or less on the book. Don't forget static asset serving, even if not managed by web2py a bad setting can slow down the page rendering quite a bit.
On Monday, April 15, 2013 7:26:10 PM UTC+2, Lamps902 wrote: > > Hi, group. I'd like to ask a very general question, but one of great > utility: what are some ways to go about finding performance bottlenecks in > your web2py page? What are some specific resource hogs and sources of > diminished performance that you've encountered in your web2py pages (I > imagine DB-related things come up quite a bit here)? Do you have any > recommendations regarding how to address these issues? Thanks! > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
