Comments for Caching woes.

Caching woes.

2009-03-25T16:51:56Z

Before I dig deeper in to what is happening here I wanted to see if someone else encountered this problem and had a solution worked.

I'm working with MT 4.23 Pro with the community patch applied and an unchanged Mid-Century Template Set along with client content (6426 entries) and assets (12262 images) that I imported.

Rebuilds are extremely slow (how slow we'll see in a minute) so I turned on performance logging and went in to DebugMode 12 to get slow template build and D:OD queries reports.

My sidebar module is cached. I have memcached running and have tried caching using that and Apache SSI methods.

In the performance log I get entries like these while rebuilding.

[Wed Mar 25 16:18:09 2009] domU-12-31-38-00-A4-C4 pt-times: pid=28221, uri=[/mt/admin?next=0&start_time=1237997514&total=6238&entry_id=&old_next=&old_previous=&is_new=&__mode=rebuild&limit=&type=Individual&old_status=&blog_id=9&offset=4], mem_start=7608, mem_end=61912, tag_assets[type:image]=62.47898, Total=70.54554
[Wed Mar 25 16:19:22 2009] domU-12-31-38-00-A4-C4 pt-times: pid=28249, uri=[/mt/admin?next=0&start_time=1237997514&total=6238&entry_id=&old_next=&old_previous=&is_new=&__mode=rebuild&limit=&type=Individual&old_status=&blog_id=9&offset=5], mem_start=7608, mem_end=61956, tag_assets[type:image]=61.42105, Total=70.22215

Inidividual entries are taking 70 seconds to build and MT is only building one per iteration (note the offset). This is also reporting that mt:assets is taking up most of the time that I've tracked down to the Galley module. This is why I have to cache that module and more.

If I remove (ignore) the sidebar I see performance numbers I'd expect:

[Wed Mar 25 16:33:15 2009] domU-12-31-38-00-A4-C4 pt-times: pid=28461, uri=[/mt/admin?next=0&start_time=1237998784&total=6238&entry_id=&old_next=&old_previous=&is_new=&__mode=rebuild&limit=&type=Individual&old_status=&blog_id=9&offset=40], mem_start=7604, mem_end=28636, Total=2.96603
[Wed Mar 25 16:33:20 2009] domU-12-31-38-00-A4-C4 pt-times: pid=28464, uri=[/mt/admin?next=0&start_time=1237998784&total=6238&entry_id=&old_next=&old_previous=&is_new=&__mode=rebuild&limit=&type=Individual&old_status=&blog_id=9&offset=80], mem_start=7608, mem_end=28596, Total=2.96874

Just under 3 second for 40 entries is acceptable.

With the sidebar in and caching turned on I noticed some odd calls from the Data::ObjectDriver queries:

DELETE FROM mt_asset_meta WHERE (asset_meta_asset_id = ?) AND (asset_meta_type = ?) : 0.035363s / 441 = 0.000080s avg (first 0.000063s, min 0.000002s, max 0.000476s)

UPDATE mt_asset SET asset_file_ext = ?, asset_modified_on = ?, asset_created_on = ? WHERE (asset_id = ?) : 0.079201s / 361 = 0.000219s avg (first 0.000083s, min 0.000002s, max 0.031106s)

Why are these happening during a rebuild? Could this be why the sidebar and gallery keeps rebuilding and killing performance? BTW: I only have the packaged plugins in use and even some of those I have disabled.

As I understand the expire on event mode of caching, these would trigger that event and clear out the cache. That said using a TTL of 30 minutes did help either.

Any thoughts, tips or tricks would be appreciated.

Comment from Jay Allen on 2009-03-25

2009-03-25T19:25:57Z

1. Is this under FastCGI?
2. The SQL for assets may be those for thumbnail generation. Possible?
3. Not sure what the "Galley module" is, but sounds like you have a winner. Search and destroy!

Comment from Byrne Reese on 2009-03-25

2009-03-25T19:48:43Z

From IM:

byrnereese: the assets being deleted might have something to do with asset thumbnail generation
[12:42pm] byrnereese: however that shouldn't happen
[12:43pm] byrnereese: but that seems like the most likely candidate for a bug
[12:43pm] tappnel: that is another problem i am having.
[12:43pm] byrnereese: my guess is that MT is deleting and then regenerating the thumbnail for every page
[12:43pm] tappnel: i imported all of these assets and...
[12:43pm] tappnel: the manage assets displays a "missing image" message and icons.
[12:44pm] tappnel: yet at the same time I can click the view asset link and see the file
[12:44pm] byrnereese: i wonder if the import wasn't performed properly
[12:44pm] tappnel: and that file displays in the entry.
[12:44pm] byrnereese: or something
[12:44pm] tappnel: perhaps.
[12:44pm] byrnereese: here is an experiment
[12:44pm] byrnereese: try installing MC into a separate blog
[12:44pm] tappnel: i was trying to figure out how you force thumbnail generation.
[12:44pm] byrnereese: add some assets the normal way
[12:45pm] byrnereese: turn on debugging and see if you keep seeing MT make those mt_asset db calls
[12:45pm] tappnel: OK.
[12:45pm] byrnereese: if you do then there is a bug in MT that needs to get fixed obviously
[12:45pm] tappnel: I did post an image through the WYSIWYG and that worked as it should.
[12:45pm] byrnereese: if not, then I would suspect that the import was not done properly.
[12:45pm] byrnereese: MT is probably simply having difficulty finding the actual cached thumbnail on disk
[12:46pm] byrnereese: so it deletes a record of it
[12:46pm] tappnel: I will try it in another blog and see what happens there.
[12:46pm] byrnereese: and recreates it
[12:46pm] byrnereese: it might also be a permissions issue in assets_c
[12:46pm] byrnereese: maybe

Comment from Timothy Appnel on 2009-03-25

2009-03-25T19:53:43Z

1. Not under FastCGI. This is a development environment that I didn't want to keep restarting each time I make a change to the system or some code.

2. Perhaps. That is another issue I'm having. All the images I imported display a missing image message and icon when I go into manage > assets. I'm not getting any errors from the web or command line though.

3. GalleRy module. It's displayed at the top of the side bar picture of the homepage screen shot here:

http://www.movabletype.org/documentation/themes/mid-century.html

Thing is the latest entries and comment modules are being repetitively rebuilt unnecessarily slowing down rebuilds. The mt:assets markup in the Gallery module is a worse offender.