HHVM with WooCommerce (work-around)

v3
#1

I just rolled out a new site on my server that is running a store with WooCommerce. Because woo is heavy, I am also trying out HHVM on this site for the first time to try to increase performance. I used the tutorial here: https://rtcamp.com/tutorials/php/hhvm-with-fpm-fallback/ to get started and mostly things were working fine. I found that there is a conflict between W3tc and HHVM. It’s a known issue ( https://wordpress.org/support/topic/warning-with-hhvm ). I turned off W3tc and found the site was running faster without it anyway.

Mostly everything worked fine under HHVM, but I did run into one issue during checkout. I don’t know if this is peculiar to the paypal pro payment gateway that my client uses, or if it is a more general problem, but when a customer tried to checkout, HHVM threw a 500 error and the checkout process just hung up and never completed.

I worked around it by falling back to php-fpm just for the checkout. Here’s how I did that with the nginx conf for the site:

# can't currently use hhvm for cart checkout
set $backend hhvm;
if ($query_string ~ "action=woocommerce_checkout") {
  set $backend php;
}

location ~ \.php$ {
  set $rt_session "";
  
  if ($http_cookie ~* "wp_woocommerce_session_[^=]*=([^%]+)%7C") {
    set $rt_session wp_woocommerce_session_$1;
  }
  
  if ($skip_cache = 0 ) {
    more_clear_headers "Set-Cookie*";
    set $rt_session "";
  }
  
  fastcgi_cache_key "$scheme$request_method$host$request_uri$rt_session";
  
  try_files $uri =404;
  include fastcgi_params;
  fastcgi_pass $backend;
  
  fastcgi_cache_bypass $skip_cache;
  fastcgi_no_cache $skip_cache;
  
  fastcgi_cache WORDPRESS;
}

note the fastcgi_pass $backend; in the location block. This uses the variable set before the location block to run just the checkout ajax request via the php-fpm back end.

to go with that, here is my upstream.conf modified from the version presented in the rtcamp hhvm tutorial:

# Common upstream settings
upstream php {
  # server unix:/run/php5-fpm.sock;
  server 127.0.0.1:9000;
}

upstream hhvm {
  server 127.0.0.1:8000;
  server 127.0.0.1:9000 backup;
}

upstream debug {
  # Debug Pool
  server 127.0.0.1:9001;
}
#2

@pjv

If you could share your error logs, so that we can detect the issue.

#3

hi @harshadyeola,

i’m sorry, but the error logs are not of any help. I was not running a debug version of hhvm and there was nothing at all in the hhvm error log. The nginx error log just showed a generic 500 error when trying to respond to the request for an ajax call during the checkout process that included the query action=woocommerce_checkout. So i was really just posting how I worked around the problem and not asking for a solution.

The method I showed above can be adapted to any problem that HHVM has with a particular request. In fact I later found that it also choked on a request used by a newsletter plugin we installed and just added that request string into the if statement like this:

if ($query_string ~ "action=woocommerce_checkout|page=wysija_subscribers&action=lists") {
    set $backend php;
}

The basic idea is that if you don’t have the time or chops to be debugging HHVM, until the smart guys figure it out, if you want to run it but have just a couple requests that cause problems, just send those specific requests to php-fpm instead of HHVM and it then works fine.

As HHVM releases updates, I’ll periodically remove those query strings and see whether the new HHVM release can handle the request without choking. Hopefully soon it won’t be necessary at all.

How can we scale better?
#4

I was facing the same issue a while ago. It seems like HHVM mysqli support is not 100%. The solution was to force WordPress to use mysql instead of mysqli. You can read more here: http://www.webvision.sk/en/2014/11/woocommerce-place-order-500-error-on-hhvm/

#5

Hi @pjv

Thanks for sharing the issue the workaround.This sure helps the community to avoid pitfalls.

I am closing this support topic for now. Feel free to create a new support topic if you have any queries further. :slight_smile:

#6