Rommel Santor's Clog » Bugs https://rommelsantor.com/clog my exploits and misadventures in programming Thu, 04 Feb 2016 12:56:01 +0000 en-US hourly 1 https://wordpress.org/?v=4.0.38 30 Second Delay with PHP and Memcache Sessions https://rommelsantor.com/clog/2016/02/02/30-second-delay-php-memcache-sessions/ https://rommelsantor.com/clog/2016/02/02/30-second-delay-php-memcache-sessions/#comments Wed, 03 Feb 2016 07:08:02 +0000 http://rommelsantor.com/clog/?p=459 We upgraded the servers at NeatoShop.com and Neatorama.com a couple of weeks ago, and in the past week we started noticing and receiving reports that on “some” page loads there was a 30-second delay where the page seemed to hang before finally returning any content.

The common things we could put a finger on were 1) it would seem to happen with a raw/initial page load (e.g., in a brand new incognito window), 2) it would not hang up anymore after that first page load, and 3) it seemed to happen only if we loaded neatoshop.com which was then redirected to www.neatoshop.com.

It took a ton of code profiling and countless attempts to reproduce the problem (because it didn’t happen for me on every new incognito page load), but I finally traced the delay down to session_start(). This didn’t really make sense to me because we’ve used php5-memcache (obviously with Memcached) for handling sessions with redundancy across our 7 web servers, and nothing regarding sessions nor Memcached changed on our end any time recently. So what could the problem be?

It started to seem like a pointless shot in the dark to keep googling for clues, but something that stuck out in my mind were reports of session files getting locked if there were two simultaneous requests from the same user. This didn’t seem to apply since we’re dealing with Memcached sessions and not file-based sessions, but then I noticed the new memcache.lock_timeout option in php5-memcache v3.0.4 which has a default value of 15 seconds.

Hmm… 15 seconds with a lock on two simultaneous requests seems like it could result in a 30 second delay… ya think? There’s one way to find out.

I tried changing the memcache.lock_timeout value to 2 seconds then trying to repro the problem. Once it seemed like I got the hang-up to occur, I held my breath and the page hung for 4 seconds before loading. Then I changed the value to 1 second and tried again, and as I’d hoped, the loading time was 2 seconds!

Finally, I’ve reduced the value to 0 seconds and there seems to no longer be any delay. I’m not certain of any side effects or unintended consequences of setting the value to zero, but whatever they are, they are insignificant as compared to every customer on an e-commerce site occasionally being subjected to a 30-second delay. I just thought I should share this tale of woe, as I couldn’t really find any good info on it, and I’m assuming there must be others facing the same issue.

Update!

After reducing the value to zero, I started getting reports of slow load times again, which indicates a value of zero is not valid because it causes the default of 15 seconds to be used. So we’re stuck using a 1-second lock_timeout, which is the only acceptable solution, but a 2-second delay is much better than 30 seconds!

]]> https://rommelsantor.com/clog/2016/02/02/30-second-delay-php-memcache-sessions/feed/ 0 IE8 Crash – Inline-Block Scroll with DOM Append https://rommelsantor.com/clog/2011/03/02/ie8-crash-inline-block-scroll-dom-append/ https://rommelsantor.com/clog/2011/03/02/ie8-crash-inline-block-scroll-dom-append/#comments Wed, 02 Mar 2011 09:15:35 +0000 http://rommelsantor.com/clog/?p=148 Was struggling for many hours today to figure out what has turned out to be a really stupid bug in IE8. In the hopes I can prevent even a single person from wasting their day like I have trying to figure out what is wrong with my code, I’ll explain below how the bug presents itself with examples.

I’m not 100% certain of every variable required to cause the bug, but it definitely works in this example:
IE8 crash

The general structure of the page is:

<body>
<div id="outer" style="display:inline-block;overflow:auto;height:100px;">
  ... any multi-line content that forces the div to have a scrollbar ...
</div>
</body>
<script>
$("#outer").scroll(function(){
  $("<div></div>").appendTo("body");
});
</script>

In that example <body> has only the one direct child element and if you scroll it causing the appendTo() function to be called, IE8 crashes. (I’ve only tested this on Windows 7 machines. IE7 does not crash.)

This is the same example, but it works. The only difference is that a second <div> child was included within <body> but with that one change, the bug vanishes. Note that I’ve also tested this with multiple scrolling divs in body and the bug persists. It seems there must be at least one block element in <body> to prevent the bug.

Fortunately, it’s not often that one would create a page with just scrollable divs in the body.

]]> https://rommelsantor.com/clog/2011/03/02/ie8-crash-inline-block-scroll-dom-append/feed/ 1