Problem gelöst: Ab 11. April 2007 verlangsamt Microsoft Update u.U. PC nach dem Start

Posted on May 6th, 2007 by Reiner.
Categories: Deutsch, Computers.

Ein Fix zu diesem Problem ist jetzt verfügbar, aber ich empfehle, solange zu warten, bis er ab ca. 22. Mai automatisch verteilt wird, und erst danach - also so ab Juni 2007 - die automatischen Updates wieder von Windows Update auf Microsoft Update umzuschalten. Info für Spezialisten von Les Connor bei WSUS v2 client and high CPU fix (auf Englisch).

0 comments.

Ab 11. April 2007 verlangsamt Microsoft Update u.U. PC nach dem Start

Posted on April 12th, 2007 by Reiner.
Categories: Deutsch, Computers.

Es gibt plötzlich Berichte darüber, dass Microsoft Update (nicht Windows Update) den PC nach dem Starten mehrere Minuten lang sehr langsam macht.

An meinem Rechner wird eine seiner CPUs nach dem Starten von wuauclt.exe ca. 12 Minuten lang mit 100% belegt. Ältere PCs mit nur einer CPU reagieren mehrere Minuten bis zu einer Stunde lang auf keinerlei Eingaben.

Siehe z.B. Alex met SVCHOST (auf Englisch), wo ein work-around vorgestellt wird:

  1. Automatische Updates ausschalten
  2. Bei http://update.microsoft.com/ die Einstellungen so ändern, dass Microsoft Update nicht mehr verwendet wird, sondern nur noch Windows Update
  3. Automatische Updates wieder einschalten

Aktualisierungen:

 6. Mai 2007: Ein Fix ist jetzt verfügbar, aber ich empfehle, solange zu warten, bis er ab ca. 22. Mai automatisch verteilt wird, und erst danach - also so ab Juni 2007 - die automatischen Updates wieder von Windows Update auf Microsoft Update umzuschalten. Info für Spezialisten von Les Connor bei WSUS v2 client and high CPU fix (auf Englisch).

 1. Mai 2007: Das Problem scheint immer noch nicht gelöst zu sein. Siehe SVChost performance issues — hold on just a smidge longer (auf Englisch).

12. April 2007: Ich freue mich, dass auch ein echter Guru (Bradley von The SBS Diva Blog) dies z.Zt. als Mittel der Wahl empfiehlt: SVChost and flipping back to Windows Update  (auf Englisch)

Wahrscheinlich ist dieses Problem bei Microsoft bereits bekannt und arbeitet z.Zt. an Hot-Fixes. Siehe z.B.:

Ein m.E. gute Darstellung des Problems gibt es bei Windows Update / Microsoft Update / svchost / Autoupdate / 100% CPU - Patrick Hopp (auf Englisch)

1 comment.

Microsoft Update may clog your CPU at 100% on boot starting Apr 11, 2007

Posted on April 12th, 2007 by Reiner.
Categories: English, Computers.

There have been reports, that Microsoft Update (not Windows Update) may clog your CPU for some time after booting your PC.

On my system wuauclt.exe keeps one of its CPUs busy at 100% for about 12 minutes.

See Alex met SVCHOST, where Wim describes a work-around:

  1. Disable Automatic Updates on the computer
  2. Go to http://update.microsoft.com/, choose “Change Settings”, select “To stop using Microsoft Update” at the bottom of the page and then check the box “Disable Microsoft Update software and let me use Windows Update only”
  3. Re-enable Automatic Updates

Updates:

06-May-07: The problem has been fixed, but I suggest to wait until the fix will be distributed automatically starting about 22-May-07. Threafter - in June - you should then switch back from Windows Update to Microsoft Update. Technical info from Les Connor at WSUS v2 client and high CPU fix.

01-May-07: The problem appears not to have been solved yet. See SVChost performance issues — hold on just a smidge longer.

12-Apr-07: Glad a real guru (Bradley from The SBS Diva Blog) backs this somewhat bleak work-around: SVChost and flipping back to Windows Update  

Microsoft may be aware of the problem and is preparing hot-fixes. See

There’s a post that gives some details at Windows Update / Microsoft Update / svchost / Autoupdate / 100% CPU - Patrick Hopp

1 comment.

WP-Cache 2.1 revisited: Have x-gzip and gzip compression share same cache slot

Posted on April 10th, 2007 by Reiner.
Categories: English, Computers.

While working on the 304 not modified case that causes excessive traffic for RSS feeds, I encountered a mild weakness within the compression code, that causes both gzip and x-gzip variants of a particular page to use separate cache slots (i.e. two separate files). That’s quite redundant, as x-gzip is just a lagacy term to invoke gzip processing and both x-gzip and gzip produce identical contents. 

Now, only a single cache slot is being used for both and the value of the Content-Encoding header (either gzip or x-gzip) is no longer cached, but instead derived from the current request being served. 

There’s no code here, as it will be included within the 304 not modified version.

0 comments.

I claimed my blog at Technorati

Posted on March 1st, 2007 by Reiner.
Categories: English, Uncategorized.

We’ll see, what (and if) it’s good for: Technorati Profile

0 comments.

A Weekend in Barcelona - Ein Wochenende in Barcelona

Posted on February 28th, 2007 by Reiner.
Categories: Deutsch, English, Uncategorized.

Barcelona Feb 2007Just all the pictures dumped from my camera using FirmTools AlbumCreator.

Hier einfach alle Bilder aus meiner Kamera, aufbereitet mit FirmTools AlbumCreator.

0 comments.

How to prevent Search Everything from returning duplicate hits with WordPress 2.1

Posted on February 19th, 2007 by Reiner.
Categories: English, Computers.

After upgrading to WordPress 2.1 Search Everything often returns the same pages multiple times. 

22-Feb-07 Update: The information below has been superceeded, as Dan has just released version 3.01 of the plugin that includes code to prevent duplicate hits.

One of a my friends runs a property management agency, where WordPress is used as an internal knowledge base to document internal procedures and the like. Quite often, valuable information is not contained within the main post, but added later as a comment. Search Everything makes sure that this information can be searched and retrieved.

After upgrading to WordPress 2.1 and installing Search Everything Version 2.6, searches will quite often return the very same pages multiple times.

I had a look at both Search Everything and WordPress Code and found that WordPress 2.1 does not use the distinct option when querying the databse, but provides a filter instead that may, at its discretion, return the magic ‘DISTINCT’ to cancel duplicate entries. The distinct option may need additional resources within the database, so I believe, it’s off by default for performance reasons.

Here’s my fix (the bolded lines below), which will cause WordPress to cancel duplicate results. It should be applied to the search_everything2.php file and requires WordPress 2.1+ to work (but won’t harm older WordPress releases) :

if ("true" == get_option('SE2_use_metadata_search')) {
  add_filter('posts_where', 'SE2_search_metadata');
  add_filter('posts_join', 'SE2_search_metadata_join');
  SE2_log("searching metadata");
  }            

// http://blog.saddey.net/?p=167
add_filter(’posts_distinct’, SE2_search_distinct);              

// http://blog.saddey.net/?p=167
function SE2_search_distinct($distinct) {
  if($distinct == ”) {
    return ‘DISTINCT’;
  }
  return $distinct;
}              

//search pages
function SE2_search_pages($where) {
  global $wp_query;

The fix is very basic and may apply the distinct clause, even when it might not be required as dictated by your Search Everything options. But I don’t think, there’ll be any problem with this and would like to leave the final inclusion to the author of Search Everything. Thanks to Dan Cameron for this great plugin! 

After having implemented the fix, I found, that the concept for the fix has already been outlined at WordPress Hackers - Getting double/triple posts listed on some blogs ten days ago.

Aditya has posted a fix as well, which was taken from Google Code, but I believe that my version more closely adheres to WordPress 2.1 standards (the ‘posts_distinct’ just returns a keyword for the tasks it’s supposed to instead of modifying the whole query).

1 comment.

How to prevent WP-Cache from changing a Feed’s Content-Type to text/html

Posted on February 18th, 2007 by Reiner.
Categories: English, Computers.

After upgrading to WP 2.1, Kelson had to downgrade WP-Cache 2.1 to a tweaked 2.0.17, because with RSS feeds WP-Cache 2.1 would,  when serving a request from its cache, always return Content-Type text/html instead of Content-Type text/xml.

Why does WP-Cache not reproduce the original Content-Type text/xml?

I had a look at wp_cache_shutdown_callback within wp-cache-phase2.php and found that all and everything should work perfectly.

Disabling WP-Cache’s code that forcibly sends a Content-Type text/html header if there is none, led me to the mazes ob flush(), ob_flush(), ob_end_flush(), headers_sent() and the like. And to the interesting fact, that…

WP-Cache does not see at least some of the http response headers, that have been output by WordPress code. Why?

If WP-Cache misses some headers, the reason must be located somewhere in the way it tries to retrieve them.  wp_cache_get_response_headers() first interrogates apache_response_headers() and, if this function does not exist, reverts to headers_list().

headers_list() docs clearly state, that it returns both, headers that have already been sent and those that have not yet been sent, i.e. are about to be sent. That might be the ones, that WP-Cache is missing after all. headers_list() requires PHP >= 5, but even then, headers_list() may not work at all due to Bug #29683 headers_list() func. return empty array.

apache_response_headers() requires PHP >= 4.3 (>= 4.3.3 with NSAPI)  and its docs are a little bit vague on platform requirements. There are some  hints on how to have it “working good”.

  • For apache_response_headers() working good, you need to set up output_buffering = Off in php.ini. Ok, I’ve checken on that one, it’s still set to its default = off.
  • If apache_response_headers() returns an empty array, try calling flush() before and it’ll get filled.  Bingo :-)   At least on my system using the Vistered Little Theme. Strange though, that it was just the Content-Type header, that was missing, the other ones were included even without the flush()…

Fix for wp_cache_get_response_headers within wp-cache-phase2.php:

function wp_cache_get_response_headers() {
  if(function_exists('apache_response_headers')) {
    flush(); // fix text/html on feeds
    $headers = apache_response_headers();
  } else if(function_exists(’headers_list’)) {
    $headers = array();
    foreach(headers_list() as $hdr) {
      list($header_name, $header_value) = explode(’: ‘, $hdr, 2);
      $headers[$header_name] = $header_value;
    }
  } else
    $headers = null;              

  return $headers;
}

Last-not-least an honorable mention of ieHTTPHeaders , that made it possible to spy on both the actual http request and response headers and much more. Thanks to Jonas!

There’s another interesting area as to when a page needs refreshing. It’s the If-Modified-Since header. Do WordPress and WP-Cache support this technique, and why not? I’ll try to cope with that one in a future post…

13 comments.

Why WP-Cache and Spam Preventers like Spam Karma 2.2 will never work in harmony

Posted on February 15th, 2007 by Reiner.
Categories: English, Computers.

WP-Cache and Spam Karma both implement strategies that are contradictory by their very nature. Let’s see why.  

In the past, I got along with a remarkably short comment blacklist (hand**b, pi**ing, tran****ual, b**bs) , that was able to block over 5000 spam attempts during the last year, but still allowed too many false nagatives to slip through for manual approval to be avoided. Personally, I don’t like having to approve - or being approved, for that matter :-)

When upgrading to WordPress 2.1, I was looking for a better way to prevent spam. I soon ruled out Akismet, because Akismet requires a key and I was unable to find the right kind of key within a reasonable amount of time. My blog is both a private one and non-commercial, but still runs on my own server (10 feet from my bed, see Small is beautiful - WordPress in a Handbag).

When leaving a comment at Kelson’s Updated to WordPress 2.1, I was quite impressed by a challenge popup, that I could trace back to Spam Karma 2.2. Wow, that’s cool - I must have this.

Within minutes, I downloaded, installed - and donated to - Spam Karma 2.2.

Due to my CPU’s inferior processing power, I’m using WP-Cache (with expire time set to 60 days) in order to speed up page display. To my dismay, WP-Cache caused new comments not to be displayed at all. Everton’s article at How To Fix WP-Cache And Spam Karma 2 (SK2) Issues led me to Priv’s SK2-WP-Cache-Compatibility plugin which sucessfully fixed the case of the missing comments. So far, so good.

Everything ought to be in perfect harmony by now.
But is it really?

The answer may be no, and here’s why:

WP-Cache works very much like a camera. It lets WordPress generate the HTML for a page, which is then captured and resent by WP-Cache on all subsequent request for the same page. That’s the secret to its stunning performance. A page, once cached, is returned just as fast as if it were plain static HTML. WP-Cache is quite smart about building the key for a cached page. Keys include your WordPress cookies so as to avoid disclosure of private pages. There’s even a hack that enables WP-Cache to properly snapshot gzipped pages as well, thus avoiding the computational expense of compressing identical contents more than once (see WP-Cache 2.1 revisited: Compression)

Spam Karma contains quite a number of advanced features, some of which can easily be revealed by looking the HTML of a page. Three of those may not work as designed when used in conjunction with WP-Cache: 

  • The stopwatch plugin injects the current time when the page was requested into the HTML of the page and then monitors the time, it takes a visitor to read your article before hitting the comment button.
  • The encrypted payload plugin injects unique data into the HTML that is checked for by Spam Karma when hitting the comment button. The actual data changes on a regular interval schedule so as not to be avoided by smart spamming applets.

These two techniques very much rely on Spam Karma being able to prepare individual output for each and every particular page request. This is defeated by WP-Cache returning static content that may have been prepared hours or days ago in response to another request for the same page, eventually causing Spam Karma to no longer accept or misinterpret the values returned.

It’ll be an interesting challenge as to how these conflicting goals can be met at the same time:

  • Always return the same static image for a particular page. 
  • Return different contents for each request.

7 comments.

WP-Cache 2.1 revisited: Compression

Posted on February 11th, 2007 by Reiner.
Categories: English, Computers.

Speeding up WordPress appears to be the play of the month, see 5 Ways to Speed Up Your Site. I ran into an interesting post from Nick Georgakis in which he presents both an in-depth discussion and working code to properly enable compression with WP-Cache. The main idea is, that in order to support compression, WP-Cache must keep compressed cached files separate from uncompressed ones. This is achieved by appending the compression method to the url when allocating and retrieving cache entries. That way, browsers will always be returned a version of the content they will be able to handle - depending on whether they requested compressed contents or not in the first place. 

I’ve adopted Nick’s code to the current 2.1 version of the WP-Cache and applied some minor amendments, e.g. replaced the somewhat complicated gzcompress call with the more up-to-date gzencode. Be warned though, that it requires at least PHP 4.2.

What it comes down to: WP-Cache is a very effective plugin that lets WordPress serve content just as if it were plain static html. Why not have WP-Cache take a snapshot of the compressed image as well?

20 comments.

Older » « Newer