I am starting to think the design loading everything in models with every
request, all though makes for rapid development isn't a very good design.
Maybe for common settings in witch case the folder shouldn't be called
models.

I need to go through my app completely and remove everything from models as
when ever I do any request it is getting loaded and the banner engine hits
the server every 3 times every 5 seconds. The bottle neck is definitely the
DB/layer as the old site connecting to the same db is having loading
problems now also.

On Fri, May 11, 2012 at 2:43 PM, Michele Comitini <
michele.comit...@gmail.com> wrote:

> > Connections = (pool_size) * (number of web2py processes)
> >
> > So if you have 10 threads  and pool_size = 4
> > 1 * 4 = 4 connections
> >
> > If you have 10 processes (each with 6 threads):
> > 10 * 4 = 40 connections
> >
> > As you can see the number of processes is not a term of the computation.
> > You must count the number of concurrent processes, the number of
> > threads does not count, same for the number of requests in the nginx
> > queue.
> AHEM... its too late here...
> "...the number of processes is not a term ..." should read "...the
> number of threads is not a term ..."
>
> >
> > If the db seems to be locked you can do on the db server host:
> >
> > ps ax | grep TRANSACTION
> >
> > you should get many postgres processes IDLE IN TRANSACTION.  It is a
> > symptom of web2py taking long to commit the transaction.
> > If you do not use the db in some complex view you can try to put a
> > db.rollback() at the beginning of the controller.
> > Are you using any web2py scripts (cron or the like)? check that you do
> > not keep the transaction open if the process is long.  Use alway
> > db.commit!
> >
> > mic
>



-- 
-- 
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

Reply via email to