is identity slow?

[Davide Bertola]

The same page with the same template
takes 0.4/0.5 seconds more if you are a logged user.

For an unlogged user the whole page tales 0.2 sec
and it uses the database more than identity may need.

You can see that if I'm online : http://dade.ath.cx:8080/
refreshing many times and logging with "foo"/"bar"

(Powerbook G4 1ghz, sqlite database)

[Kevin Dangoor]

On 12/31/05, Davide Bertola <adm...@gmail.com> wrote:
>
> The same page with the same template
> takes 0.4/0.5 seconds more if you are a logged user.

That's a big difference! I don't know how it could take that much longer.

>
> For an unlogged user the whole page tales 0.2 sec
> and it uses the database more than identity may need.
>
> You can see that if I'm online : http://dade.ath.cx:8080/
> refreshing many times and logging with "foo"/"bar"
>
> (Powerbook G4 1ghz, sqlite database)

Hmm.... I remember Jeff saying something about identity updating a
table. sqlite locks the whole database when anything is being updated.
(And, on the Mac, it waits for a full sync before releasing the lock.)
I wonder if something like that is going on: your request goes in,
database is getting updated, image tries to load but database is
locked, it waits, etc...
I wouldn't expect an update on *every* hit though.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[Cliff Wells]

Kevin Dangoor wrote:
> On 12/31/05, Davide Bertola <adm...@gmail.com> wrote:
>
>> The same page with the same template
>> takes 0.4/0.5 seconds more if you are a logged user.
>>
>
> That's a big difference! I don't know how it could take that much longer.
>
>
>> For an unlogged user the whole page tales 0.2 sec
>> and it uses the database more than identity may need.
>>
>> You can see that if I'm online : http://dade.ath.cx:8080/
>> refreshing many times and logging with "foo"/"bar"
>>
>> (Powerbook G4 1ghz, sqlite database)
>>
>
> Hmm.... I remember Jeff saying something about identity updating a
> table. sqlite locks the whole database when anything is being updated.
> (And, on the Mac, it waits for a full sync before releasing the lock.)
> I wonder if something like that is going on: your request goes in,
> database is getting updated, image tries to load but database is
> locked, it waits, etc...
> I wouldn't expect an update on *every* hit though.
>

Actually, watching my postgresql logs, it does seem to do an update
every hit:

LOG: statement: BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
LOG: statement: SELECT id, user_id, expiry, value FROM tg_secret_token
WHERE user_id = 'username'
LOG: statement: UPDATE tg_secret_token SET expiry = '2005-12-31
01:48:49' WHERE id = 2
LOG: statement: SELECT id, user_id, email_address, display_name,
password, created FROM tg_user WHERE user_id = 'username'
LOG: statement: SELECT group_id FROM tg_user_group WHERE user_id = 1
LOG: statement: SELECT group_id, display_name, created FROM tg_group
WHERE id = 1
LOG: statement: SELECT group_id FROM tg_user_group WHERE user_id = 1
LOG: statement: SELECT permission_id FROM tg_group_permission WHERE
group_id = 1
LOG: statement: SELECT permission_id, description FROM tg_permission
WHERE id = 1
LOG: statement: END

[Jason Chu]

My understanding was that (after a recent change), it set the expiry date
in the db. Because of this you have to update the expiry date on every
request.

Jason

--
If you understand, things are just as they are. If you do not understand,
things are just as they are.

[Jeff Watkins]

Identity does the following for *every* HTTP request that is handled by TurboGears (CherryPy):

load the user's secret token

load the user record and compute the user's groups and privileges

update the user's secret token expiration date

One of the things I'm thinking of doing is modifying the current SqlObjectIdentityProvider to use SQL statements rather than SQLObject directly. I would expect this to be *much* faster.

I don't know what priority Kevin puts on this, but I'm willing to make this a post 0.9 or even post 1.0 fix. (I'm a little busy at the moment.)

--

Jeff Watkins

http://newburyportion.com/

"Just because you have the right to do something, doesn't mean it's the right thing to do."

-- Fred Friendly, former president of CBS News

[Dave Warnock]

Jeff,

> One of the things I'm thinking of doing is modifying the current
> SqlObjectIdentityProvider to use SQL statements rather than SQLObject
> directly. I would expect this to be *much* faster.

Please not. It reduces portability, reduces pressure to optimise SQL
Object and later might cause issues with SQL Object caching.

> load the user's secret token
> load the user record and compute the user's groups and privileges

Both these could be helped in the future by improved SQL Object caching

> update the user's secret token expiration date

This is not a time critical update. Why not put it in a queue and have a
background thread saving the queue to the database? This way the main
process is not delayed.

Regards

Dave