Live data from Hacker News

Ask HN: Has HN been slow/spotty loading for you?

news.ycombinator.com

11–20 of 46 posts

Re: Ask HN: Has HN been slow/spotty loading for you?

#11
post #6

Yes, I noticed it too. I don't know what the backend is, but if it's on a single shared machine it might be too many inquires on the hardware at once. Maybe ask the hosting company to move it to a machine with a lower load.

As of 2 years ago, it was hosted on a "3.0 GHz Core whatever, 12 GB RAM, 64-bit FreeBSD 7.1" - it's certainly not a shared machine. ( http://news.ycombinator.com/item?id=516122 ) rtm is the sysadmin for HN (yes, that rtm: http://en.wikipedia.org/wiki/Robert_Tappan_Morris ).

> rtm is the sysadmin for HN (yes, that rtm: http://en.wikipedia.org/wiki/Robert_Tappan_Morris)

It always makes me laugh when someone with no knowledge of a website offers advice to that site's sysadmin. It's especially funny when that sysadmin is of the calibre of RTM.

Re: Ask HN: Has HN been slow/spotty loading for you?

#17
I'm looking at this page in Safari inspector. The only element that took more than milliseconds to load is prowidget.php (but that may be related to its size, and my slow ass connection).

inspector has flagged 3 elements with "You could save bandwidth by having your web server compress this transfer with gzip or zlib": item, news.css and propres.php

Re: Ask HN: Has HN been slow/spotty loading for you?

#19
It is slow for me as well. It seems that page needs some optimizations in order to be served and rendered faster when the server is under heavy loads.

1. I checked responses using FireBug plugin and it seems that pages are served uncompressed. For example the front page of the site (only html) is 31K uncompressed, with gzip compression it becomes 6.3K (80% smaller size means 80% less bandwidth to use). Most of web servers support compression.

2. All pages seem to be generated on every request, e.g. no HTTP cache is used on server side. Because I did not found any response headers set by caches. If for example, each page was cached just for 1 to 5 seconds it will reduce the stress on database and cpu significantly. On the other hand it will not impact user experience, because cached version is short lived and fresh results will appear on time. For example the front page is the most requested page of the site, assume that it is requested 100 times per second which means 100 queries to the database etc. If this page is cached for 1 second queries and html composition is reduced to 1 time per second. Personally, HTTP caching on server side is my favorite choice because you don't need to modify the program to use it. (super-fast Varnish cache is the most flexible solution I found).

Post reply on HN