[wp-trac] [WordPress Trac] #14348: If it's a HEAD request, stop after the head!

WordPress Trac wp-trac at lists.automattic.com
Thu Jul 22 02:38:30 UTC 2010


#14348: If it's a HEAD request, stop after the head!
-----------------------------+----------------------------------------------
 Reporter:  mitchoyoshitaka  |       Owner:                 
     Type:  defect (bug)     |      Status:  new            
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Performance      |     Version:  3.0            
 Severity:  normal           |    Keywords:  has-patch      
-----------------------------+----------------------------------------------

Comment(by mitchoyoshitaka):

 Replying to [comment:7 jacobsantos]:
 > A browser might send a HEAD request in order to determine whether or not
 the content in cache needs to be updated. If that is the case, then it is
 the same as exit()ing for the Not modified.

 Indeed. This is the primary use of HEAD, and it's precisely why, if have a
 WP page which is oft linked to and crawlers want to check the status of,
 it will get hit hard. Caching helps, but WP itself should exit when it's
 not necessary to continue.

 The reason I ran into this is because my Yet Another Related Posts Plugin
 page on my website gets linked to in a lot of RSS feeds, which are in turn
 handled by FeedBurner, and FeedBurner likes to check to see that linked-to
 websites have been updated or not (apparently). I thus get almost 3000
 HEAD hits a day on this page... more than the number of GETs.

 [[Image(http://img.skitch.com/20100722-pjks2t95tnybupumwfek8u8qtd.jpg)]]

 Since instituting this patch on my site, the CPU usage (across Media
 Temple's distributed "grid", so it says GPU = grid performance unit) of
 the script went down to two thirds that of producing the full GET
 response. Before the change they were identical. Yes, I am running WP
 Super Cache.

 For me, Media Temple sometimes charges by the GPU. For others, this could
 translate directly into CPU and RAM usage. This is clearly a performance
 issue.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14348#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list