Question

Dang, OpenStudy, your site is running wonderfully today. And by "wonderfully", I mean really slowly.

I'd like to chalk this up to a problem on my side, but I've used at least 5 computers--three lab, one library, and one personal--all updated fully, with Firefox, and with 10+mb/s connections.

I'm not particularly bothered, because this isn't a site that needs to update constantly, but it'd be nice if it was a bit less jerky.

Answer 1

I agree with badref, the site is really growing slow, and I also have the updated version of Firefox, just earlier, my computer crashed because of this issue.

Answer 2

My computer is faster than the speed of lighting no problem nice job OS for making things smoothly as possible :D

Answer 3

OpenStudy, here are a few suggestions (I'm a Web developer and here to help):
-You don't need to deliver 700kb for this page. Seriously. I have no idea as to why you're delivering a 277.5 kb script file. That's unjustifiable these days.
-Please just cache the user's Facebook icons, set cache headers accordingly, and serve them from S3. Don't keep retrieving them from Facebook; I can see each user's FB userid because you're making my browser fetch their pictures. Not cool in so many ways.
-Combine and minify your MathJax, Quant, Uservoice, and "/javascripts/compressed/...js" script files.
-Combine and minify your MathJax, Uservoice stylesheets. Do the same for your own stylesheets.
-Only some of your assets are being served by CDNs. Fix that.
-Check your liftAjax and CometAjax libraries; something is weird about the way they're loading.

Answer 4

...How does one get so much information about how this website operates?

Answer 5

indeed how did you get that information?

Answer 6

ya farm gonna answer this :D

Answer 7

I used Firebug to get this stuff. And I didn't want to come off as a Negative Nancy or anything - just wanted to help. :p

Answer 8

We're experiencing some slowness due to some issues with the code on the server. All I can say at this point is "we're working on it" - but this problem in particular (the roughly 6-7 second pauses) aren't being caused by your browsers.

UnexpectedEOF: Thanks for the thoughts. The compressed script we serve also compresses in several of the realtime libraries we use. That said, our codebase is pretty large. This whole realtime thing ain't easy. ;) We're making the move to more CDN'd assets in the near near future, but problems like this are obviously higher priority for us at the moment.

Answer 9

Ok do you guy do incremental computations or do you do big changes
if you do incremental computations you don't have to start from scratch
if you do big changes you have to start from scratch each time
(does it sound like i know what i'm talking about or do i need to work on this some more )

Answer 10

myininaya: o.O

Answer 11

Good to hear, farm! Although I'm unsure about everything being "compressed"; there seem to be a number of scripts delivered over the wire without any minification (regardless of whether they've been gzipped). Also, are you guys using Rails/some Ruby Gem to generate your stylesheets dynamically? There some weird crap in the head comments of your stylesheets that hint at what version you're using...

Answer 12

we can use a dynamic algorithm to modify mapreduce

Answer 13

I'd like to add in that, uh, if you do SCIENCE and MATH to your computers they'll run faster?

Answer 14

so that we can not start from scratch each time
but you guys probably use dynamic algorithm since your data is constantly changing

Answer 15

UnexpectedEOF: Right, so there are some scripts and some portions of scripts that aren't minified for various reasons. Everything that we write internally is in that minified file you saw. In regard to stylesheets, no, they are not generated dynamically.

We write our stylings in sass and use compass to compile them into CSS. This is done once during deployment and then the resulting CSS used. We're not a Rails app, so using Rails to do that dynamically would be painful. lol.

Answer 16

But yeah, we're working on tightening up the downwire transfer amount as we are able.

Answer 17

farm google percolator is an example of doing incremental computations instead of batching it up

Answer 18

myininaya: I'm sorry, I'm still lost on the relevance. XD hahaha

Answer 19

ok lol that was the part i was wondering
does it apply
i guess not
lol

Answer 20

i thought in theory that this would make the site faster
but i guess it does not apply

Answer 21

Hey EOF, thanks for reaching out. Farmdawg touched on most of yr points pretty good, but I'll add what I can.

As far as script size goes, considering the real-time aspect of this site and the fact that you can stay on it for hours with all updates in real-time on top of all the features the UI offers, I don't think a 277.5 kb file is unjustifiable.

In regard to caching, your browser *should* cache any resources because they only change whenever we deploy new code. This includes the html, the scripts, and even FB avatars. In fact, caching it is even running into some problems on occasion.

All of our internal code is minified and compressed into a single js file. We have some code in the pipeline for the next week that will serve all our assets via S3. Regarding the liftAjax and cometAjax, what problems are you running into? That stuff is core to our backend framework.

Thanks for reaching out. Always good to hear a developer perspective, especially from a GT grad :).

Answer 22

Also, to all the others, thanks for reporting this. We've definitely noticed it being sluggish since the deploy yesterday. As always, we're always looking for ways to make things I Can't Believe It's Not Butter-smooth

Answer 23

Matt,

Thanks for the response! My main beef with the FB avatars is kinda twofold: the fact that users' FB ids are exposed (more a privacy thing), and the fact that you need to rely on another server to get these files when S3 will likely serve them up in various availability zones faster was the main point. I meant to suggest server-side caching on your servers, not the client's caching (which y'all already do).

Although your code code may be minified (though I'm still skeptical that 277.5 is needed for a minified real-time notification system ;p), some of the other libraries are not. LiftAjax and CometAjax are being served up in non-minified fashion (which is not a huge deal since they're light) as is MathJax (which is much larger, and takes a great deal longer), and a number of related inline stylesheets haven't been combined *or* minified. For instance, panes.css is a whopping 31.9 kb (out of your ~700 base kb), and took almost 791ms to download - 2 to 3 times as long as the other stylesheets. Combining these could also reduce the number of round trips in first loads, which would be a huge time saver.

Let me know how it progresses! Do you guys have a dev blog or anything like that?

Answer 24

*core code

Answer 25

Ahoy EOF - I'll let Matt answer any questions regarding the FB photos. That code predates me.

In re: the CSS files, that's in the category of things that will be served from S3 when the next iteration of the compression/deployment code makes it out of code review and testing.

In regard to the blog, we do have our company blog: http://blog.openstudy.com - and additionally each of us also post to our own blogs now and again. (You can find those links in the Blogroll on the company blog or on the "About Us" page.) I've got a couple of posts ready to go out, but I don't want to spoil the surprise of the new features I'm working on - so I'm sitting on them until those are out the door. ;)