X

Aggregator

CodeSOD: The Big Pictures

The Daily WTF
1 month 4 weeks ago

Loading times for web pages is one of the key metrics we like to tune. Users will put up with a lot if they feel like they application is responsive. So when Caivs was handed 20MB of PHP and told, "one of the key pages takes like 30-45 seconds to load. Figure out why," it was at least a clear goal.

Combing through that gigantic pile of code to try and understand what was happening was an uphill battle. Eventually, Caivs just decided to check the traffic logs while running the application. That highlighted a huge spike in traffic every time the page loaded, and that helped Caivs narrow down exactly where the problem was.

$first_image = ''; foreach($images as $the_image) { $image = $the_image['url']; if(file_exists($config->base_url.'/uploads/'.$image)) { if($first_image=='') { $first_image = $image; } $image_dimensions = '&w=648&h=432'; $get_dimensions = getimagesize('http://old.datacenter.ip.address/'.$config->base_url.'/uploads/'.$image); if($get_dimensions[0] < $get_dimensions[1]) $image_dimensions = '&h=432'; echo '<li>'.$config->base_url.'/timthumb.php?src='.$config->base_url.'/uploads/'.$image.'&w=125&h=80&zc=1'), 'javascript:;', array('onclick'=>'$(\'.image_gallery .feature .image\').html(\''.$config->base_url.'/timthumb.php?src='.$config->base_url.'/uploads/'.$image.$image_dimensions.'&zc=1').'\');$(\'.image_gallery .feature .title\').show();$(\'.image_gallery .feature .title\').html("'.str_replace('"', '', $the_image['Image Description']).'");$(\'.image_gallery .bar ul li a\').removeClass(\'active\');$(\'.image_gallery .bar ul li\').removeClass(\'active\');$(this).addClass(\'active\');$(this).parents(\'li\').addClass(\'active\');sidebarHeight();curImg=$(this).attr(\'id\');translate()','id'=>$img_num)).'</li>'; $img_num++; } }

For every image they want to display in a gallery, they echo out a list item for it, which that part makes sense- more or less. The mix of PHP, JavaScript, JQuery, and HTML tags is ugly and awful and I hate it. But that's just a prosaic kind of awful, background radiation of looking at PHP code. Yes, it should be launched into the Kupier belt (it doesn't deserve the higher delta-V required to launch it into the sun), but that's not why we're here.

The cause of the long load times was in the lines above- where for each image, we getimagesize- a function which downloads the image and checks its stats, all so we can set $image_dimensions. Which, presumably, the server hosting the images uses the query string to resize the returned image.

All this is to check- if the height is greater than the width we force the height to be 432 pixels, otherwise we force the whole image to be 648x432 pixels.

Now, the server supplying those images had absolutely no caching, so that meant for every image request it needed to resize the image before sending. And for reasons which were unclear, if the requested aspect ratio were wildly different than the actual aspect ratio, it would also sometimes just refused to resize and return a gigantic original image file. But someone also had thought about the perils of badly behaved clients downloading too many images, so if a single host were requesting too many images, it would start throttling the responses.

When you add all this up, it meant that this PHP web application was getting throttled by its own file server, because it was requesting too many images, too quickly. Any reasonable user load hitting it would be viewed as an attempted denial of service attack on the file hosting backend.

Caivs was able to simply remove the check on filesize, and add a few CSS rules which ensured that files in the gallery wouldn't misbehave terribly. The performance problems went away- at least for that page of the application. Buried in that 20MB of PHP/HTML code, there were plenty more places where things could go wrong.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!
Remy Porter

Open Document Format Turns 20

Slashdot
1 month 4 weeks ago
The Open Document Format reached its 20th anniversary on May 1, marking two decades since OASIS approved the XML-based standard originally developed by Sun Microsystems from StarOffice code. Even as the format has seen adoption by several governments including the UK, India, and Brazil, plus organizations like NATO, Microsoft Office's proprietary formats remain the de facto standard. Microsoft countered ODF by developing Office Open XML, eventually getting it standardized through Ecma International. "ODF is much more than a technical specification: it is a symbol of freedom of choice, support for interoperability and protection of users from the commercial strategies of Big Tech," said Eliane Domingos, Chair of the Document Foundation, which oversees LibreOffice -- a fork created after Oracle acquired Sun.

Read more of this story at Slashdot.

msmash