You have this for connection string :
try:
if request.env.http_host.split(':')[1]!='':
db=DAL('postgres://username:[email protected]:5432/database_name',
migrate_enabled=True, lazy_tables=True)
except Exception, e:
db=DAL('postgres://username:[email protected]:5432/database_name',
migrate_enabled=False, lazy_tables=True, pool_size=1)
I use pool_size=1 because I am with nginx, but I think that if you set
bigger number it make things faster with Apache...
Richard
On Wed, Mar 27, 2013 at 2:23 PM, Cliff Kachinske <[email protected]> wrote:
> I agree that indexing and connection pooling are the big hitters.
>
> My belief is that getting the connection is the big bottleneck in apps
> powered by a db.
>
> Smart indexing goes without saying, I think.
>
> On Wednesday, March 27, 2013 12:57:17 PM UTC-4, Jonathan Lundell wrote:
>
>> On 27 Mar 2013, at 9:46 AM, Derek <[email protected]> wrote:
>>
>> I was wondering if there is anything such as a "Go-Live Checklist" for
>> W2P apps. Like things you want to check before you go live, or
>> optimizations you can enable once your 'development' phase is done.
>>
>> For example:
>>
>> 1. Disable migrations
>> 2. Enable 'lazy tables'
>> 3. Enable DB Cache on queries
>> 4. Add @cache decorator to cacheable views.
>> 5. Add session.forget for methods which don't use the session object.
>> 6. Enable connection pooling depending on the database.
>>
>> Anyone have ideas on what to add to (or change in) the checklist? I
>> understand that not all developers can enable all optimizations, and you
>> should go through and test everything after you've "optimized" to make sure
>> the site still functions, but having this checklist as like a
>> pre-go-live-check might be a good thing to have for those of us who are
>> less experienced at deployments.
>>
>>
>>
>> compile the app
>> consider moving code to (imported) modules
>> controller-specific models
>> database indexes
>>
>> It'd be useful to try to attach order-of-magnitude
>> performance-improvement estimates to these things. I'd guess that caching
>> and optimal indexing would ordinarily be the big winners, though the
>> investment in some of them (disabling migrations, compiling the app, lazy
>> tables, connection pooling) is so small that they fall into the
>> why-would-you-not? category.
>>
>> --
>
> ---
> 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.
>
>
>
--
---
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.
