I find that I'm blogging less ever since I upgraded to MT 4 because the whole system seems to run so slowly now.

I've been with MT since the days of 2.661, which was fine. I later upgraded to 3.15 and that was fine. Ever since upgrading to MT 4, I've been absolutely hating the experience because it's so slow. I upgraded from 4.01 to 4.1 in hopes that it would speed up, but it's still awful. I then switched over from CGI to FastCGI hoping to speed up MT, and it might have made a bit of a difference, but MT is still god awful slow.

Is there anything else I can do? Am I missing something?

I'm having the same problem with tremendously slow speeds during any publishing. I'm running MT 4.1. The lengthy wait time to process anything makes frequent publishing nearly impossible.

I'd like to hear if others are having the same problem and what, if anything, anyone has been able to do about it.

Thanks
www.sarudama.com

Likewise. I did a clean install of 4.1 and imported the ~1700 entries from my old 3.1 site. I hit "Publish" last night at around 8pm, and it's *still* running, 19 hours later.

I am using the standard template, unmodified in any way at all, and static archives.

This is insane.

i do have the same problem as well. it takes too long to publish even the default template.

Can you qualify what is slow? Rebuilds? The interface in general? Renaming tags?

Why use static publishing for *so* many entries?

using the default archive mapping, it would take me to rebuild 2500 entries about 10 minutes. If i use archive mapping that goes something like %y/%m/<$mtentryid$>.html, then it would take minimum 24 hours to rebuild all the entries (both on default template) the 10 minutes one is acceptable but 24 hours?

i dont know about others but in my thats what i really like about MT. I rather use static publishing rather than dynamic and then using cache to speed up the system

I know they are testing some performance enhancements at the moment.

For now lets look at the use suspects:

* LaunchBackgroundTasks: Is it enabled in mt-config? If so try disabling it.
* Stats dashboard widget: Try disabling it to import log in times to the admin database, particularly if you have a lot of posts and comments.
* Notifications: Are they enabled and how many. Notifications have to ping each site and wait for a response, if the sites listed are incorrect or slow, this will effect you performance.
* Templates: Are they default or customised. Does everything that is building actually need to be built?

* LaunchBackgroundTasks: In my experience, this should be enabled, otherwise the user interface becomes really slow. Only after I enabled it did Mt 4 and 4.1 become somewhat usable.

My site is really really slow too - I'm talking 20 seconds to post a comment, over 60 to publish a page, 3 minutes and 59 seconds to publish a comment and a rebuild goes all night - as to the comment about dynamic publishing - that is one of the main reasons to use MT rather than WP - MT has static publishing ensuring the site stays online when the database goes down.
I logged a ticket with dreamhost today and the responded with the following - anyone got any ideas on what I can do to troubleshoot this?
I'm running the following plugins -


Blog Cloner 2.0
Blog Janitor 1.1
GravatarInjector.pl
Multiblog 2.0
StyleCatcher 2.0
Textile 2.04
WXR Importer 1.1
Widget Manager 1.0
reCaptch 0.2
Markdown 1.01
SmartyPants 1.5.1
SpamLookup - Lookups 2.11
SpamLookup - Link 2.11
SpamLookup - Keyword Filter 2.1


Blog contains 3175 pages, 1481 comments.

Handler_read_rnd 729 M The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries
that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use
keys properly.

Handler_read_rnd_next 1,803 M The number of requests to read the next row in the data file. This is high if you are doing a lot of
table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the
indexes you have.


Both numbers should be zero. Do you have any third party plugins or add-ons that are requiring whole table scans? Have you optimized your
database recently? Moveable type should have some optimization scripts to keep things running smoothly.

That's at least half your problem right there. DH databases are notoriously slow - that is when they're not having some other network issue as well. I switched to MediaTemple gridservice a few months ago, and the performance level improved a huge amount from DH. A little more expensive, but well worth it imho. They quote $20/month, but you can Google for discount coupons, plus they give additional discount if you pay a whole year when you sign up.. ended up about $14/month for me I think. Sorry if that offends you (DH users are often very defensive about anyone saying anything bad about it), but seriously, DH were good once upon a time, but those days have gone. Warm fuzzies only go so far if the product sucks.

I have a fresh install on a very small site and I too notice that MT4.1 is at times intolerably slow, really uselessly slow. Since I'm fresh out of the box, and I trust that my host can't be *that* bad (pair), what are the basic steps I can do?

What are the 'at times' bits?

4.2 is due soon and that has some major performance improvements http://www.movabletype.org/2008/05/welcome...le_type_42.html

Yes but unfortunately that doesn't answer the problem. Nothing personal but no response on the problem with whole table scans doesn't help. Wordpress running on the same server at the same time doesn't have a problem returning a search result or publishing/saving files. Yes Wordpress is dynamic so doesn't have files to write, but by your logic the performance should be worse as wordpress is totally reliant on a database that is "notoriously slow".
Yes I agree the databases are slow, but that doesn't seem to be the problem here.
I'm waiting for 4.2 but I'm not sure how long that is going to be (although I can probably risk trying out a beta)