TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why Reddit's been slow lately (dev group post)

94 pointsby rufoover 14 years ago

10 comments

daloreover 14 years ago
What if instead of looking up each user in the thread to see if they are a friend, they just serve the same page to all users. Then a bit of javascript loads up your friend list from the server and uses dynamic css to change the style of your friends username to the friend style.<p>That way everyone can share the cache page, and the dynamic icing is separate.
评论 #1789290 未加载
评论 #1789877 未加载
评论 #1789436 未加载
评论 #1789147 未加载
评论 #1789123 未加载
antirezover 14 years ago
Apparently Reddit folks don't like Redis too much (private email exchange), but I'm practically sure that Redis could help them so much here...<p>There are two strategies to mitigate reddit problems using Redis IMHO, one is simple to plug, one is advanced.<p>Strategy #1: Use Redis as a cache that does not need to be recomputed, instead of memcached.<p>To do this what they should do is things like, for all the recent "hot" news, to take everything inside Redis and update the Redis side when they write to the database.<p>For instance they could use a Redis hash for every news to store all the comments of a given news, indexed by comment id for easy update, so every time there is to render the comment page just a Redis call HGETALL is needed to fetch everything, like in a cache, but still with the ability to update single items easily (including vote counters if needed, using HICNRBY).<p>The same for firendship relations and so forth. Every place can be reimplemented using an updatable cache, starting from the slower parts.<p>Strategy #2: Use Redis directly as the data store, killing the need of a cache.<p>This needs a major redesign, but probably it can be done incrementally starting from #1, because when using Redis as a smart cache you write both the code to read and update the cache, so eventually killing the code that updates the "real" database will make Redis the only store, or it is possible to still retain the code updating the old data store just to have another copy of the whole dataset where it is easy to run complex queries for data mining and so forth, that is something an SQL database does well but Redis does not.<p>I think that David King evaluated Redis in contrast to Cassandra, and he did not liked the lack of cluster solution with failover, resharding and so forth (what we are tying to do with redis cluster), but I think he missed part of the point that Redis can be used in many different ways, more as a flexible tool than a pre-cooked solution, and in their case the "smart cache" is probably the best approach.<p>If Reddis will reconsider the issue giving Redis a chance I'm here to help.
mikey_pover 14 years ago
Here's your sign: "7s of that was waiting on memcached."<p>If memcache is slower than your DB, you're doing something wrong.
评论 #1790125 未加载
评论 #1790095 未加载
smackfuover 14 years ago
"A request that I just made on my staging instance took 13s (!) to render the front page. That's on its own cache so it should be slower than the live site, but that's still pretty ridiculous."<p>I'm actually seeing that kind of speeds on the live site front page.
aarongoughover 14 years ago
I'm curious as to how they're structuring the data for their comment trees. Does each comment only have one parent? That parent either being another comment or the parent article? Are they using nested sets?<p>My preferred alternative is to have all comments have 2 separate parent fields. One that always points to the parent article and another that points to the parent comment if it has one, null otherwise.<p>Structuring the data this way means that you can fetch all the comments for a particular article <i>very</i> quickly and if you wish simply hand that raw data over to the client to be structured using JavaScript, which helps offload some of the work your server would otherwise be doing...<p>&#60;/armchair_development&#62;
评论 #1789611 未加载
iampimsover 14 years ago
<p><pre><code> But when we render the Comment back to you in that same request we need the ID that the comment will have, but we don't know the ID until we write it out. </code></pre> Wouldn't something like Snowflake help for this particular case?<p><pre><code> Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees. </code></pre> <a href="http://github.com/twitter/snowflake" rel="nofollow">http://github.com/twitter/snowflake</a><p>Kellan (from Flickr) has a neat post about <i>Ticket servers</i>: <a href="http://laughingmeme.org/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/" rel="nofollow">http://laughingmeme.org/2010/02/08/ticket-servers-distribute...</a>
xtacyover 14 years ago
The author of the post also says that the EC2 network is "slow". Does anyone have numbers about the performance of EC2 network in general, and why this is so?
评论 #1789256 未加载
AgentConundrumover 14 years ago
As a bit of a side note, as a regular user of reddit it felt a bit odd to see this as from "David King".<p>It says something about the level of interaction between the reddit admins and its users that I recognize him primarily as "ketralnis".
评论 #1789708 未加载
elblancoover 14 years ago
Reddit is <i>always</i> going through slow phases. I bet those probably coincide with growth phases and they run rather lean (or so I've heard). I'd be more worried if they started getting very fast, that might mean their user base is shrinking and they have too much infrastructure.
shuriover 14 years ago
Start with graceful degradation when things get tough? (Less comments, top friends,...).
评论 #1789445 未加载