Viewing 2 replies - 1 through 2 (of 2 total)
  • I think this is a cool concept, and may play very well for heavily-dynamic sites (especially those with logins and personalized content). For the more average, static site, especially those that have been slashed/dugg before, the usual solution is wp-cache or the equivalent — delivering static (well, near-static) content is faster than hitting the database at all and running a ton of dynamic php processing.

    It remains to be seen whether throttling can ‘play nice’ with the average wp-cache setup. My guess is it’ll come in handy on sites not running wp-cache because of dynamic data, and thus need the ability to throttle-down with high loads.

    Should be interesting to see how this plays out… ?? ??

    -d

    Thread Starter mutube

    (@mutube)

    Thanks for the feedback david.

    You’re right that for smaller sites WP-Cache is a good system (I use it on my own site actually). However, it’s a bit of a sledgehammer to crack a nut. WP-Cache runs whether your site is experience heavy load or no load – no dynamic funstuff, ever. It also has no effect on bandwidth usage (and associated costs) because the pages are stuck at the maximum size.

    What I hope to be able to do is hook WP-Cache into Throttle so that WP-Cache can remain switched off up until the point where the load is getting tricky. By this point minor plugins (e.g. “Top Links” “Most Comments” scripts) will have been disabled and the page output will be smaller as a result.

    Of course, the success of Throttle is based on other plugins’ support. Without that few people will install – which is why I’m concentrating on building additional plugins myself. Hopefully one of them will justify installing the underlying API.

    Any suggestions you have would be most welcome!

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘WordPress Throttle vs. Digg and Slashdot’ is closed to new replies.