[TYPO3-english] Hunging select from fe_sessions and fe_users

[ries van Twisk]

The easy answer is "This is how TYPO3 works"..

I do believe core people made some changes in that area where
sessions are stored/retreived, they need to correct this if I am  
wrong. But
this was done for 4.3 I think.

I think TYPO3 just tried to find the user for the current session,
for search engines this is indeed quite problamatic.

One hack you could make 'somewhere' (don't ask me where)
is when a search engine indexes your site you disable session  
management.

May be some other people have done that already or know a better way.

Ries



On Mar 25, 2009, at 11:03 PM, Vahan Amirbekyan wrote:

> Ries, thanks much for your response, it gave me a few ideas that I am
> trying out now ( drop and recreate indexes is one of them ..)
> Tell me one thing please as I do not have time now to investigate it.
> Why do we see this queries on connections that do not have users  
> logged in?
> I got yahoo crawling now my site and tons of these queries just crush
> the server.
> Why typo3 queries fe_users at all for connection without users on the
> client side?
> or i am reading the situation wrong?
>
>
> ries van Twisk wrote:
>>
>> On Mar 25, 2009, at 8:14 PM, Vahan Amirbekyan wrote:
>>
>>> guys,
>>> I am seeing tons of queries like this one in the show process:
>>>
>>> SELECT * FROM fe_sessions,fe_users WHERE
>>> fe_sessions.ses_id = 'e361c16a9f' AND fe_sessions.ses_name =
>>> 'fe_typo_user'
>>> AND fe_sessions.ses_userid = fe_users.uid
>>> AND (fe_sessions.ses_iplock='38.99'OR
>>> fe_sessions.ses_iplock='[DISABLED]')
>>> AND fe_sessions.ses_hashlock=268278894 AND fe_users.disable=0 AND
>>> fe_users.deleted=0 AND (fe_users.starttime<=1238029426) AND
>>> (fe_users.endtime=0 OR fe_users.endtime>1238029426)
>>>
>>>
>>> I added indexes on fe_sessions.ses_userid and  
>>> fe_sessions.ses_hashlock
>>> but it did not help much.
>>>
>>> First, why suddenly I am seeing this selects?
>>> What code are they from?
>>> And should I use MyISAM or InnoDB for these fe_sessions and fe_users
>>> tables?
>>> I am using InnoDB.
>>> _______________________________________________
>>
>>
>>
>> I don't have a direct answer, but be reminded that MySQL doesn't  
>> support
>> bitmap indexes.
>> Adding a couple of indexes fill not gain you much, and MySQL 'might'
>> even select the incorrect index
>> under some conditions.
>>
>> Check if you have an index on fe_sessions.ses_id, this fields seems  
>> to
>> be the one with the highest cardinality,
>> check that to be sure, I do this from the top of my head.
>>
>> You might want to try to set fe_sessions to a innoDB type, I am not  
>> sure
>> if a lot of deletes happen on that table,
>> MyISAM has a horrible track record when you need high concurency  
>> (lot's
>> of read/write on the same table).
>>
>> Current advice is to remove the indexes and re-investigate, check  
>> if you
>> have an index on fe_sessions.ses_id.
>>
>> Dmitry knows more about this stuff.. I am not really a MySQL guy.
>>
>> Ries
>>
>>
>>
>>
>>
> _______________________________________________
> TYPO3-english mailing list
> TYPO3-english at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-english



			regards, Ries van Twisk


-------------------------------------------------------------------------------------------------
Ries van Twisk
tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS  
WebORB PostgreSQL DB-Architect
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk
Phone: +1-810-476-4196
SIP: +1-747-690-5133