<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Mod_perl on Hashbang.ca</title>
		<link>https://hashbang.ca/tag/mod_perl</link>
		<description>Recent content in Mod_perl on Hashbang.ca</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Wed, 03 Jun 2015 21:31:00 -0700</lastBuildDate>
		
			<atom:link href="https://hashbang.ca/tag/mod_perl/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Diagnosing performance degradation under adverse circumstances</title>
				<link>https://hashbang.ca/post/diagnosing-performance-degradation-under-adverse-circumstances</link>
				<pubDate>Wed, 03 Jun 2015 21:31:00 -0700</pubDate>
				<guid>https://hashbang.ca/post/diagnosing-performance-degradation-under-adverse-circumstances/</guid>
				<description>&lt;small&gt;[This post is a few years old and was never published. Recently, I was reminded about memcached slab imbalance, which in turn reminded me of this post.]&lt;/small&gt;&#xA;&#xA;&lt;p&gt;At work, we encountered a sudden and precipitous performance regression on one particular page of a legacy application. It&amp;rsquo;s a Perl web application, running under mod_perl, using &lt;code&gt;ModPerl::RegistryLoader&lt;/code&gt; to compile scripts at server startup, and &lt;code&gt;Apache::DBI&lt;/code&gt; to provide persistent database connections.&lt;/p&gt;&#xA;&lt;p&gt;Our users suddenly began complaining about one particular page being &amp;ldquo;three times slower than normal.&amp;rdquo; Later examination of the Apache logs showed a 20x(!!) slowdown.&lt;/p&gt;&#xA;&lt;p&gt;Investigating this performance problem was interesting because we didn&amp;rsquo;t have good access to required data, and our technology choices slowed us down or completely prevented us from collecting it. Although we solved the mystery, the experience had several important lessons.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
