[TYPO3-english] unwanted cHash is generated in 50% links from USER_INT plugin

[Dmitry Dulepov]

Hi!

Dmitry Martynenko wrote:
> Today I have tried to understand RealURL algorithm when it decode
> urls...
> My brain begun to boil :)

Welcome to the RealURL world! :D

> But two things I have noticed:
> 
> 1) tx_realurl_chashcache table has duplicates in chash
> spurl_hash                              chash_string
> 9f8a1c532a40eb127d76b4e221c6ebc8        62c889e8ca
> 643da9fa524eb2e7f8336c14287c424e        62c889e8ca
> 2ffab1a8c7b2e0d138fac498c5c33cdc        988e2e027d
> e432e8ef171e75a02d52051a29a79fb2        988e2e027d
> 
> How it can be?
> Should chash_string be unique?

Not just should, it must (by definition). Unfortunately the way cHash generated does not make it unuqie. cHash is made by truncating md5 value, which makes it non–unique.

> 2) Our server begun to increase time for all SQL queries and
> I try to log slow queries (> 100 ms) from class.t3lib_db.php
> 
> Most of them was like:
> SELECT /*! SQL_NO_CACHE */ content
> FROM tx_realurl_urlencodecache
> WHERE url_hash='43d5475f5d7dc35690cb8ab3d7683679' AND tstamp>1232035875
> 
> I think because this table has more then 450 000 records, and it's
> index size greater than 30 Mb, and long index and key length take lot
> of time.
> 
> I don't know how to speedup this.

I do not remember why SQL_NO_CACHE is there. I remember there was a reason for it. You can try to remove that and see if it helps.

-- 
Dmitry Dulepov
TYPO3 core team
"Sometimes they go bad. No one knows why" (Cameron, TSCC, "Dungeons&Dragons")