[TYPO3-english] Hunging select from fe_sessions and fe_users

[Vahan Amirbekyan]

thank you rias again,
I do like Typo3 but sometimes it drives me crazy with its 
over-engineered solutions.

ries van Twisk wrote:
> 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
> 
> 
> 
> 
> 
>