[TYPO3-performance] TS-Rendering - IMG_RESOURCE - 622 ms - Solution

JoH asenau info at cybercraft.de
Wed Sep 30 00:50:17 CEST 2009


>>>> So I don't think we can say for sure, that the new way definitely
>>>> will be a performance increase, just by comparing the functions
>>>> directly.
>>>> Each time the new check decides "false", while the old check would
>>>> have decided "true", we will create a new file.
>>> I guess that depends whether the mtime changes a lot without any
>>> actual change of the content. This might happen if you touch()
>>> files for some reason. The file size shouldn't change without
>>> reason. Any change of size must force a recreation (the check for
>>> the mtime can be omitted in this case).
>>
>> i sometimes had some trouble with servers where the ftp-client set
>> chmod 700 on all files, so the apache had no right to alter. So i
>> have to make an chmod -R *
>>
>> but IMHO that is an wrong server setup, so it should not get too much
>> attention:)
>
> Is a config switch worth the hassle? A single if will cost less than
> a file system access, so it won't hurt much. IMHO in normal
> circumstances mod. time is enough, but those with special needs can
> use the old md5 method.

So let's see which options we've got so far:
1 different mtime => same content or different content
2 different mtime => same size or different size
3 different size => different mtime and (different content or same content)
4 different content => different mtime and (different size or same size)

Since we want to avoid 4 the only way to go seems to be 3, since 1 and 2
might lead to a performance loss.

There 's still one problem left:
What if the size didn't change at all, but the content did?
This might be an edge case for true color photos like TIF or JPG, but not
for GIF.
Changing a color while not touching the pixels will often lead to the same
size.
If we don't check the content, no change of such a GIF image will ever make
it to the frontend.

So it seems there is a reason why the current check is using content and not
size or time.
On the other hand it might be a good idea to do a double check:
First check the mtime and _only_ if that has changed, check the content.

This way we would still get a much better performance, because only changed
files would be checked by the slower function, while we would still be on
the safe side for all scenarios.

Just another 2 cent

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com
TYPO3 workshops: http://workshops.eqony.com




More information about the TYPO3-performance mailing list