The Imgur Blog http://imgur.com/blog Tue, 18 Jun 2013 19:55:54 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.1 Tech Tuesday: Running HBase on EC2 http://feedproxy.google.com/~r/TheImgurBlog/~3/S-B8v7GPerM/ http://imgur.com/blog/2013/06/18/tech-tuesday-running-hbase-on-ec2/#comments Tue, 18 Jun 2013 19:55:54 +0000 Sarah http://imgur.com/blog/?p=2761 Since our last post about HBase, we’ve been doing a lot of experimentation on EC2. We’ve learned so many things about how to run HBase in an elastic environment. You run into many of the same issues that you do on dedicated hardware, but you deal with them differently in many cases. If you search online, you may read that running Hadoop and HBase on EC2 is a bad idea, but that is no longer the case. Companies like Pinterest have been doing so successfully, and it’s an inspiration for us to do well. There was a lot of research on our part, and I’d like to share some of our findings in hopes that it will help others trying to work on EC2.

Storage volumes for DataNodes

AWS provides two types of storage: instance store (ephemeral) volumes and EBS volumes. In addition, EBS volumes can be optimized by using provisioned IOPS. We’ve played around with both types, and run numerous tests using Linux tools like fio and dd. This was to determine the type of storage that would be best for our DataNodes.

We found that instance stores outperform EBS volumes when it comes to sequential I/O, while EBS drives are better at random access patterns when using provisioned IOPS of 200 and above.

What does this tell us? HDFS is designed for sequential I/O. If we can minimize the number of disk seeks then we can probably get some good performance using instance store volumes.

We like EBS with provisioned IOPS volumes because of their various beneficial properties. They can be as big as a 1TB, and data in them will persist after the instance is restarted. You can mount many of them on an instance to spread the I/O and adding more EBS drives increases write performance. They are expensive, however, so we discarded this approach. We also discarded standard EBS because it cannot deliver consistent performance.

Needless to say, our DataNodes use instance store volumes. If we run out of space or if we need more I/O, we’ll add more instances to the cluster. Easy enough with EC2.

Instance types and root volume

There are a few options for this. We chose m1.xlarge instances. The reason is that it provides a good balance of resources. 1.6TB of storage distributed among four volumes and 15 GB of RAM to feed a memory-hungry HBase. Another option could have been m1.large, but it only supports 7.5 GB of RAM and 2x420GB volumes (the HBase experts recommend ‘a lot’ of disks per server). For clusters that are CPU bound c1.xlarge instances might be appropriate. I’ve also heard of cases where SSD storage is used. This is probably for clusters that require very high write throughput.

We’ll try m1.xlarge instances for now and see how that works in production. We can always change instance types if we need to. Lastly, all our instances are EBS-backed. Definitely something worth doing. The cost difference is minimal, and it is much easier to work with if we need to make changes to the root device.

MapReduce

Initially, I thought we would use the HBase cluster to run MapReduce jobs, but then I remembered that Amazon EMR exists! It’s cool if you can run MapReduce jobs in your own HBase cluster, but then you introduce a new class of problems. For instance, HBase could take a performance hit if a running job is competing for CPU and I/O resources. You’d have to configure your cluster such that it takes HBase and MR into account. Still, there are reasons for why you might run jobs in your HBase cluster. Data locality is the best one I can think of: you reduce network activity and increase job performance.

With that said, we have ‘light’ and ‘heavy’ jobs. Light jobs are run in the HBase cluster. The idea is that such jobs will have a minimal effect on performance. Heavy jobs will be run on EMR and insert data into HBase if they need to. We don’t have many jobs yet, but as we write more, this is what we’ll try.

Rack awareness

Hadoop can be configured for rack awareness. This means that HFile blocks can be replicated on different racks for higher failure-tolerance. On EC2, you can treat availability-zones as racks. If one availability-zone goes down, we can count on the data being in another availability-zone.

There were concerns that cross-AZ traffic would be slow. We ran some tests to know exactly how much, and we found that response time is unaffected, and that latency increased by a negligible amount. Thus, performance was good. Another concern is the cost to send data from one AZ to another which is $0.01/GB. It doesn’t sound like much, but at scale it can add up pretty quickly. Our cluster is small so the extra cost is acceptable, and in production it’s always nice to have another layer of failure-tolerance.

HBase Backups

We are lucky to be in a time where HBase Snapshots are a thing. Previously, and this was only about three months ago, backups had to be done by dumping a table on a row by row basis, or by copying the underlying HFiles while HBase was actively making changes to the file system. A year ago, I wrote a tool that did the latter, but it meant that performance could be affected since I/O and network activity would increase during the backup stage. With built-in HBase Snapshots, there is minimal impact on the cluster because there is no need to copy any HFiles, and the snapshots are generated very quickly.

If we need to restore a table, it can also be done with minimal effect on the cluster. Soon we will be exporting those snapshots to S3 for safekeeping. We’ve already tested this approach and it works well. The only issue we see is the increased I/O at the HDFS level while we copy files in and out of S3.

There are many other aspects of the HBase cluster that we have not mentioned here. It’s a lot to cover, but these were some of the topics that we initially explored when we started this project. We’ve made a lot of progress. Our goal is to have HBase in production in the next few weeks serving real time requests.

Carlos
Software Engineer

]]> http://imgur.com/blog/2013/06/18/tech-tuesday-running-hbase-on-ec2/feed/ 0 http://imgur.com/blog/2013/06/18/tech-tuesday-running-hbase-on-ec2/ Recreate the Awkwardness Contest Winners http://feedproxy.google.com/~r/TheImgurBlog/~3/m9cfIOElmQA/ http://imgur.com/blog/2013/06/18/recreate-the-awkwardness-winners/#comments Tue, 18 Jun 2013 16:53:12 +0000 Sarah http://imgur.com/blog/?p=2633 Thanks to all who entered the Recreate the Awkwardness Contest for the cringe-worthy outfits, haunting expressions and uncomfortable poses. Somehow these recreations managed to be even more awkward than the originals.

Special thanks to our friends at Awkward Family Photos for the original images used for this contest and great prizes.

Without further ado, the winners!

First place


submitted by laece

Second place


Submitted by otfbeacon

Third place


Submitted by ChrissyJustian

Don’t stop the weirdness now! Check out the full album, including all winners and entries:

Shower your favorites in upvotes by visiting the Recreate the Awkwardness Gallery.

]]> http://imgur.com/blog/2013/06/18/recreate-the-awkwardness-winners/feed/ 1 http://imgur.com/blog/2013/06/18/recreate-the-awkwardness-winners/ Tech Tuesday: Real Time Messaging http://feedproxy.google.com/~r/TheImgurBlog/~3/p-4f00WUFxI/ http://imgur.com/blog/2013/06/11/tech-tuesday-real-time-messaging/#comments Tue, 11 Jun 2013 17:54:33 +0000 Brian http://imgur.com/blog/?p=2546 Almost a year ago, we released the Imgur messaging system. When the messaging system was first developed, we had no data on how it would be used, how much users would be communicating, or how long conversations would last. In designing the feature, we chose to go with a more email-like interface and functionality. This worked wonderfully for a long time, but recently we have found that Imgurians have been creating friendships via messaging and continuing conversations for longer. This left the messages page cluttered and your scrolling finger tired, leading us to re-think this feature set.

The new design:


We are now in the later stages of development on the new messaging system. The chat style layout allows conversations of any size to be manageable. On the right is the list of users with whom you currently have conversations. Clicking on these loads the conversation into the left panel. It also includes the number of messages in that conversation and whether or not it’s unread. The plus sign allows you to create a new conversation with a user. The left panel contains the actual conversation, starting with the newest message on the bottom. You can use the refresh button to refresh the conversation or the gear menu to delete, block or report a conversation.

This new conversation-based design updates in real time as new messages come in. In the past, developers had to rely on polling to the database every so often to see changes; websockets have changed that. They allow push notification to happen in real time. I am currently in the experimental stages of setting up a node.js cluster to handle real-time notifications and messages. Node allows you to write lightweight web servers that can handle many data-intensive tasks while allowing a large number of concurrent users. This is perfect for Imgur, since at peak times we have over 150,000 users on the site.

Our preliminary cluster design looks something like this (check out last week’s Tech Tuesday to see our full stack):

Websockets will connect to the Proxy Cluster then be routed to the node cluster where they will execute a handshake and be stored in Redis memory store. Using Redis as our memory store allows the Node cluster to scale up to meet our traffic needs without having to keep track of which server a user originally hit. When User A sends a message to User B the request will hit our WWW server and do a Redis publish. Meanwhile, the node servers are subscribed to that channel and will get an event fired when the publish is executed. When that happens, it will search Redis for User B’s socket and use that to emit a notification to User B. The result? User B is instantly notified when someone sends him a message or replies to one of his comments.

Our hope is that by offloading as much of the memory management as possible to Redis, we will take strain off our node servers and be able to still run the notoriously high memory socket.io plugin. Since this is just a preliminary infrastructure design and no benchmarking has taken place, I’d love to hear any suggestions or thoughts you guys might have. What has worked for you and what hasn’t?

Brian
Front End Engineer

]]> http://imgur.com/blog/2013/06/11/tech-tuesday-real-time-messaging/feed/ 35 http://imgur.com/blog/2013/06/11/tech-tuesday-real-time-messaging/ Imgur & Awkward Family Photos present the Recreate the Awkwardness Contest! http://feedproxy.google.com/~r/TheImgurBlog/~3/PZdHR0y7Ge4/ http://imgur.com/blog/2013/06/10/imgur-awkward-family-photos-present-the-recreate-the-awkwardness-contest/#comments Mon, 10 Jun 2013 14:42:36 +0000 Sarah http://imgur.com/blog/?p=2306 Your chance has come to re-enact the matching outfits, uncomfortable poses, and unexplainable images of awkward family photos. Stay true to the originals or add your own touch of cringe-worthiness.

The winner receives a Nikon D3100 14.2MP Digital SLR Camera plus a lifetime pro account, and more prizes from Imgur and Awkward Family Photos!

Here’s how it works:
Recreate one of the below Awkward Family Photos

Must be:
-An original creation made by you
-Submitted to the Recreate the Awkwardness Gallery (imgur.com/g/awkward) by 11:59PM PST on June 16, 2013.
-Adhering to the Contest Rules (below)

GRAND PRIZE:

SECOND PRIZE:

THIRD PRIZE:

RULES AND FINE PRINT
By entering the Recreate the Awkwardness Contest, you agree to the following Rules.

CONTEST PERIOD: Contest begins on June 10, 2013 at 12:01AM PST and ends on June 16, 2013 at 11:59PM PST.

HOW TO ENTER: NO PURCHASE NECESSARY TO ENTER OR WIN. To enter the Contest, visit the gallery located at imgur.com/g/awkward during the contest period and upload your image directly into that gallery. Make sure you are on the Recreate the Awkwardness Gallery page while uploading. Select “add to gallery” and ensure the message “you are adding _ image(s) to the recreate the awkwardness gallery” appears. Help on uploading an image can be found here: imgur.com/help. Your entry is accepted when it appears on the Recreate the Awkwardness Gallery.

AWKWARD REQUIREMENTS:
(a) Submissions are subject to all normal gallery rules and terms of service. Imgur reserves the right, in its sole discretion, to disqualify any Entrant who submits an Awkward Recreation not complying with these site wide regulations.

(b) Entries must be original, unpublished works.

(c) In the form of PNG, JPG or GIF.

(d) Only one entry per user will be accepted.

JUDGING: Each Awkward Recreation will be judged by members of the Imgur and Awkward Family Photos staff on creativity, originality, and adherence to the theme of the contest. Score and comments by users will be taken into account, but winners will be chosen solely by Imgur and Awkward Family Photos.

ELIGIBILITY: Contest is open to any account holder on Imgur. If you’re under 18, ask your parents for permission before entering this contest or recreating awkward situations.

Email sarah@imgur.com with any questions!

Brought to you by Imgur and our friends at

]]> http://imgur.com/blog/2013/06/10/imgur-awkward-family-photos-present-the-recreate-the-awkwardness-contest/feed/ 46 http://imgur.com/blog/2013/06/10/imgur-awkward-family-photos-present-the-recreate-the-awkwardness-contest/ Tech Tuesday: Our Technology Stack http://feedproxy.google.com/~r/TheImgurBlog/~3/kgEaHkEXZGQ/ http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/#comments Tue, 04 Jun 2013 21:25:27 +0000 Alan http://imgur.com/blog/?p=2417 About a year and a half ago we moved from dedicated servers over to AWS. Since then, a lot has changed in how we think about servers and what goes on behind the scenes. This Tech Tuesday is dedicated to revealing the magic behind how the site operates in the cloud.

Clusters and Instances:
Thanks to AWS, we no longer have to think on a server level. Instead, we think of everything as a cluster of instances, and an instance is essentially a virtual server where we don’t have to worry about the hardware. We never have less than two instances per cluster (in case one goes down), and some clusters can have as many as 50 during peak times. Each instance in a cluster is the same as the rest in the cluster, and every cluster is spanned across at least two availability zones in case one has an outage. We’re also able to shutdown any instance at any time (even randomly if we feel like it) because when an instance goes down another takes its place within a few minutes.

It’s a relief to not have to worry about the hardware behind the instances. If one instance becomes unresponsive, then it’s automatically terminated and a new one is spawned. As long as the instances aren’t regularly becoming unresponsive, we generally don’t care what happened to it because by the time we even notice, the new instance has already taken over. There’s no impact to the end users because the load balancers are smart enough to automatically route traffic away from problematic instances before they’re even terminated.

Every cluster has AWS AutoScaling configured for it. This lets us start up more instances automatically if we have spikes in traffic. Additionally, if we have too many instances and not enough traffic, then automatically shut some down to save a few dollars on our AWS bill. Autoscaling is arguably the best feature AWS has to offer, and if you’re not using it than you better have a good reason as to why not.

The clusters we have are: WWW, API, Upload, HAProxy, HBase, MySQL, Memcached, Redis, and ElasticSearch, for an average total of 80 instances. Each cluster handles the job that its name describes, all working together for the common goal of giving you your daily (hourly?) dose of image entertainment.

A walk through the typical Imgur request:
Every request for Imgur first has to go through the HAProxy cluster. The first thing that happens when it reaches this cluster is Nginx checks if it already has a cached version of the response available. Every single page on Imgur is cached for 5 seconds, a technique commonly called microcaching. If you’re not signed into Imgur and you’re accessing a popular page, then chances are this is where your request will end. If no cached version of the page is available, then the request goes to HAProxy which decides which cluster will handle the rest of it. If you’re accessing imgur.com then you’ll go to the WWW cluster, api.imgur.com will go to the API cluster, and if you’re uploading or editing an image, you’ll go to the Upload cluster.

When you hit the WWW cluster you’ll be round-robin’d to an instance which will handle the request. This cluster is hooked up to the Memcached, Redis, MySQL, HBase, and ElasticSearch clusters. Since the site is coded in PHP, you’ll first reach Nginx which will send you off to php-fpm. Unless all the data for the page is cached in Memcached (highly likely), then you’ll probably be getting the data from the MySQL cluster. If your request is for a gallery search, then you’ll get the data from the ElasticSearch cluster, and some specific data is also stored in Redis and HBase. By this time, the request should have has everything it needs to form the page. It pieces it all together, travels back out to the HAProxy cluster, is microcached by Nginx, and your browser renders the page. All of this happens in mere milliseconds.

Requests to serve direct images are much different. The first thing you should do when your website starts receiving lots of traffic is leverage a Content Delivery Network (CDN). The point of a CDN is to offload all requests to static files, such as images, css, and js files, to a faster network. CDNs are optimized to serve static content as fast as possible and will be much faster than anything you can hope to achieve with your own servers. All requests to images go to our CDN, which will check if a cached version of that image already exists on their servers. If it does, then the request never hits our infrastructure at all and the CDN displays the image. If no cached version of the image exists for them, for example if the image was just uploaded and is brand new, then the CDN grabs the image from Imgur and displays it. At this point, every subsequent request for that image will be cached on the CDN and Imgur is no longer responsible to displaying it.

Below is a diagram of how they all work together:


That’s about it for this Tech Tuesday. Questions are welcomed in the comments!

Alan Schaaf
Founder & CEO

]]> http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/feed/ 54 http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/ Recreate the Awkwardness Contest! http://feedproxy.google.com/~r/TheImgurBlog/~3/3wygyl3IDSU/ http://imgur.com/blog/2013/06/03/recreate-the-awkwardness-contest/#comments Mon, 03 Jun 2013 19:24:13 +0000 Sarah http://imgur.com/blog/?p=2407

Imgur and Awkward Family Photos are proud to present the Recreate the Awkwardness Contest. Follow the lead of Danny McBride and Maya Rudolph above and recreate one of these awkward family photos: http://imgur.com/a/OOFji. Stay true to the originals or add your own touch of cringe-worthiness.

The winner receives a Nikon D3100 14.2MP Digital SLR Camera plus a lifetime pro account, and more prizes from Imgur and Awkward Family Photos!

Check back on June 10 for instructions on how to submit your awkward photo recreation.

]]> http://imgur.com/blog/2013/06/03/recreate-the-awkwardness-contest/feed/ 2 http://imgur.com/blog/2013/06/03/recreate-the-awkwardness-contest/ Our Favorite Images from May 2013 http://feedproxy.google.com/~r/TheImgurBlog/~3/3c_0zfn5mQc/ http://imgur.com/blog/2013/06/01/our-favorite-images-from-may-2013/#comments Sat, 01 Jun 2013 16:11:29 +0000 Sarah http://imgur.com/blog/?p=2369 Welcome, summer! We’re glad you’re here, but first we have to pay homage to the month that came before. There were so many phenomenal images this month that it took days to narrow down to these ten gems. We hope you’re more excited about them than Armind was about his National Spelling Bee win.

Eyebrows & Mustache

Favorite comment by MyBrotherIsLuigi: Ladies, this is what happens when you leave your child alone with their father.

 

My typical day at work.

Favorite comment by MetaphoricalFox: The right amount of mayhem.

 

Google Streetview captures the glorious moment when my buddy kicks his now ex-gf out of his house

Favorite comment by Idonteatenoughfruit: Revenge is a dish best served at the side of a road.

 

What I saw when I finished mowing the lawn yesterday

Favorite comment by MichaelMendez: sir i believe your dog is spoiling.

 

Comedian Kurt Braunohler hired a sky writer to do this over LA

Favorite comment by FalseOasis: I NEED MORE FUE

 

Khaleesi

Favorite comment by ImTheSwanQueen: “Touch my beard, and we will burn you first!”

 

Summer is Coming

Favorite comment by RobbStarkKingOfTheNorth: What do we say about sunscreen? Not today.

 

6th grader advice to next years 6th grader; surprisingly deep.

Favorite comment by Caniewak: Rivaled only by “Be excellent to each other.”

 

The ritual is COMPLETE

Favorite comment by TheyStoleMyPrecious: He’s trying to summon Cathulu

 

So close

Favorite comment by creatingusernamesgivesmeanxiety: My dog waited at the door for 10 minutes to come in…all while the door was open. http://imgur.com/upN8XbT

 

]]> http://imgur.com/blog/2013/06/01/our-favorite-images-from-may-2013/feed/ 19 http://imgur.com/blog/2013/06/01/our-favorite-images-from-may-2013/ Tech Tuesday Takeover: Self-Serve Ads http://feedproxy.google.com/~r/TheImgurBlog/~3/SO6QgzAeBKQ/ http://imgur.com/blog/2013/05/28/tech-tuesday-takeover-self-serve-ads/#comments Tue, 28 May 2013 22:26:44 +0000 Sarah http://imgur.com/blog/?p=2344 Oh no! The Imgur sales guys have hijacked Tech Tuesday! Today we are going to talk a little about how we handle our advertising business. Don’t panic, this post will cover some new ad technology that we are implementing today in the hope of improving the overall role that ads have on our site.

As many of you know, we are an independent bootstrapped company. Since we offer a free service, understandably, people always want to know how we keep the lights on, pay our ginormous hosting bills and still manage to keep the Imguraffe well fed.

We are able to support the company with revenue generated from ad sales, Pro accounts, commercial hosting and schwag from the store. A sincere thanks to all of you that support us through these paid products or decide to not use Adblock while browsing Imgur!

On the ad sales side, we work with large branded advertisers as well as ad networks. Ad networks are third-party companies that work with thousands of websites and hundreds of advertisers. They act as the middleman, bringing Imgur ad campaigns from advertisers we don’t work with directly. Although we have very strict guidelines for the types of ads we accept (only two formats, no auto-sound ads, no auto-expanding ads, no pop-overs or unders), we can’t always identify every campaign that’s running. Even with a ton of screening mechanisms in place, sometimes bad ads sneak through. Please know we hate these ads, too! We use every report we get through support@imgur.com to track down the offending networks and campaigns and squash them as soon as we can.

Ads play an important role in supporting the site, but we would prefer that they add value, or at least not detract from your experience. As part of our ongoing effort to maintain better control of our ads and to improve our ad quality, we are looking to develop direct relationships with our advertisers. To forward that goal we are excited to announce a new self-serve ad platform. This new system will allow you (or your company) to easily setup an ad campaign that will be displayed to your fellow Imgurians.

How does it work? Easy.

1. Visit our self-service page
2. Choose to target US only or the entire world
3. Select your budget
4. Upload your ad (or you can create one on the platform)
5. Enter payment details and submit

After a quick review to ensure that the creative looks good and your landing page is working, we will set the campaign live, typically the same day.

Aside from knowing that our community is full of awesome, funny, good-natured folks that love cat GIFs, we have also provided a few quick stats about our audience. If you are interested in targeting a specific geography (city or country) or if have any other questions about display ads or sponsored image ads please email us at sales@imgur.com.

75M+ unique visitors (almost 50M from US)
340M total visits per month
4.1B page views per month
70% Male
Over 50% Ages 18-34

Matt
Chief Operating Officer, Imgur

]]> http://imgur.com/blog/2013/05/28/tech-tuesday-takeover-self-serve-ads/feed/ 12 http://imgur.com/blog/2013/05/28/tech-tuesday-takeover-self-serve-ads/ Tech Tuesday: jQuery DOM performance http://feedproxy.google.com/~r/TheImgurBlog/~3/rOjK0cQnMKk/ http://imgur.com/blog/2013/05/21/tech-tuesday-jquery-dom-performance/#comments Tue, 21 May 2013 16:41:35 +0000 Sarah http://imgur.com/blog/?p=2288 jQuery is called the “write less, do more” JavaScript framework. Invented by a fellow alumnus of RIT John Resig in 2006, it has changed the face of JavaScript development forever. Here at Imgur we use a lot of jQuery because it really does accomplish its aims and makes a lot of things pretty simple. The simplicity comes at a cost, however. jQuery is not nearly as fast as native DOM. Because it is a library sitting on top of the native DOM, it can never be as fast, and in certain contexts the performance penalty can become quite burdensome. We’ll examine one such context here.

If you’ve ever loaded a page on Imgur with a lot of comments, you’ll notice that it’s quite slow right now. We’re working to fix that, and part of that solution is sending comment data to the web browser to build the tree of comments rather than building it on our servers and sending out the result to you. By doing that, we off load a lot of the processing power to the web browser and also can utilize caching to make it even faster. Some pages can have a lot of comments to lay out – thousands in some cases, and each comment contains at least 19 elements, so we could be laying out around ~19,000 elements. Whether we do that in jQuery or native DOM is a choice: is the benefit of jQuery (“write less”) worth the performance penalty? Let’s examine the performance penalty to decide.

I wrote a small library called ThinDOM that sits on top of the native DOM methods and lets you do fancy chaining like jQuery. I’ve written a test suite to examine the performance characteristics of jQuery vs. using innerHTML vs. ThinDOM, and through the wonder of technology you too can replicate my results! Science!




The test page simulates very closely the actual process involved in building each caption. The results, though not expected, are a bit shocking in the differential.



Happily jQuery is getting better over time, but its performance is still lacking. The InnerHTML method, though fast, is not quite as fast as using the native DOM methods, and the difference is statistically significant (p < 2.2 E-16). ThinDOM is about twelve times faster than jQuery 2.0 edge.

jQuery, like all abstractions, leaks. The promise of jQuery is that you don’t need to know about DOM, you just need to know about HTML and JavaScript, but it leaks because, if I know a bit about DOM, I can write a library that is an order of magnitude faster, and, if I don’t know about DOM, then my code is going to be awfully slow. Knowing when to use jQuery is knowing when you aren’t going to be blindsided by these performance issues, or when the performance penalty is less than the cost in developer time – time spent writing the code.

On a site like Imgur with sometimes hundreds of thousands of people hitting images with hundreds of comments, even a small performance gain can be “worth it” since developer time is averaged out over every user. As we implement this feature over the next few weeks we hope this should make captions feel much more responsive, especially on more popular images.

I ran all tests on a machine with a Core i5 760, 16 GB of RAM, on Windows 7 SP1 on Google Chrome 26.0.1410.64 m.

Jake
Front End Engineer, Imgur

]]> http://imgur.com/blog/2013/05/21/tech-tuesday-jquery-dom-performance/feed/ 32 http://imgur.com/blog/2013/05/21/tech-tuesday-jquery-dom-performance/ Alan takes over the Imgur Twitter! http://feedproxy.google.com/~r/TheImgurBlog/~3/ZQ53FtfB9m4/ http://imgur.com/blog/2013/05/20/alan-takes-over-the-imgur-twitter/#comments Mon, 20 May 2013 22:14:12 +0000 Sarah http://imgur.com/blog/?p=2273 Join Alan Schaaf, Founder of Imgur, this Wednesday (5/22) at 4PM PST for an ask me anything–Twitter style! Alan will be taking over the official Imgur twitter (@Imgur) to answer your questions about Imgur, bombard you with cat GIFs, give you relationship advice, or tell you about his favorite images. The choice is yours.

Follow the conversation by using #AskImgur.


Now, here’s a cute sloth:

]]> http://imgur.com/blog/2013/05/20/alan-takes-over-the-imgur-twitter/feed/ 0 http://imgur.com/blog/2013/05/20/alan-takes-over-the-imgur-twitter/