I can verify that I saw this behavior on PostgreSQL back on 1.4, so I
suspect it's not DB dependant.  I use a custom authentication class and do
my own caching, so never really pursued it.  (And, in fact, forgot about it
until this message jogged my memory.)

-- Michael


On 11/17/04 8:58 AM, "Dan Moore" <[EMAIL PROTECTED]> wrote:

> Well folks, we found the issue with the 100,000 users problem.
> 
> I used p6spy to grab all the SQL statements going to the database, and
> we saw this:
> 
> 1099788107943|13|1|statement||SELECT TURBINE_USER.USER_ID,
> TURBINE_USER.LOGIN_NA
> ME, TURBINE_USER.PASSWORD_VALUE, TURBINE_USER.FIRST_NAME,
> TURBINE_USER.LAST_NAME
> , TURBINE_USER.EMAIL, TURBINE_USER.CONFIRM_VALUE,
> TURBINE_USER.MODIFIED, TURBINE
> _USER.CREATED, TURBINE_USER.LAST_LOGIN, TURBINE_USER.DISABLED,
> TURBINE_USER.OBJE
> CTDATA, TURBINE_USER.PASSWORD_CHANGED FROM TURBINE_USER WHERE
> TURBINE_USER.LOGIN
> _NAME='17215'
> 1099788107976|15|1|statement||SELECT TURBINE_USER_GROUP_ROLE.USER_ID,
> TURBINE_US
> ER_GROUP_ROLE.GROUP_ID, TURBINE_USER_GROUP_ROLE.ROLE_ID FROM
> TURBINE_USER_GROUP_
> ROLE WHERE TURBINE_USER_GROUP_ROLE.USER_ID='17215'
> 1099788108002|10|1|statement||SELECT TURBINE_ROLE.ROLE_ID,
> TURBINE_ROLE.ROLE_NAM
> E, TURBINE_ROLE.OBJECTDATA FROM TURBINE_ROLE WHERE
> TURBINE_ROLE.ROLE_ID=1
> 1099788108032|10|1|statement||SELECT TURBINE_GROUP.GROUP_ID,
> TURBINE_GROUP.GROUP
> _NAME, TURBINE_GROUP.OBJECTDATA FROM TURBINE_GROUP WHERE
> TURBINE_GROUP.GROUP_ID=1
> 
> Many many times.  In fact, these four statements were repeated around
> 60 times for one page load with 9 portlets.  I don't know why, since
> this property was set in JetspeedSecurity.properties:
> 
> services.JetspeedSecurity.caching.enable=true
> 
> This obviously slowed portlet rendering down quite a bit.  Since we are
> not using any of Jetspeed's authorization capabilities, we turned it
> off by setting this property:
> 
> services.PortalAccessController.classname=org.apache.jetspeed.services.securit
> y.
> nosecurity.NoSecurityAccessController
> 
> This helped a lot.  We saw no more of the statements mentioned above,
> and page load times go down dramatically.
> 
> Thanks for all your help.
> 
> Dan
> 
> 
> 
> --- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> 
>> Youssef Mohammed wrote:
>>> I think it has nothing to do with the portlets since the only
>> changes
>>> he (Dan) made was the number of users.
>>> I suggest to do some profiling (both IBM and Oracle stuff can help
>> )
>>> to the jetspped instance to see what is going on.
>>> I used to work on J1 last year and I did found some scalability
>> issues on it. 
>>> I donno if they still exist on not.
>>> 
>> 
>> If our resident performance expert doesn't mind, could I also
>> recommend 
>> trying the delay rendering feature, which allows for J1 to render
>> portlets in parallel.
>> By default, J1 will render portlet sequentially, meaning that portlet
>> 2 
>> doesnt start rendering until portet 1 completes and so on.
>> 
>> 
>> -- 
>> David Sean Taylor
>> Bluesunrise Software
>> [EMAIL PROTECTED]
>> [office] +01 707 773 4646
>> [mobile] +01 707 529 9194
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to