Opera always hangs up for me after a few pages of looking, sometimes instantly when loading a page. Javascript Turn-Off does nothing. Anyone know this problem? Using Opera 9.5.

It doesnt happen with like IE 7.0.

Operas just better for browsing picture sites.. You just middle-mouse on every pic, and they instantly pop a new frame up. Unlike IE, where it takes a second to pop up :/

Anyone with the same problem?

same here

It's not the servers problem itself, it seems. As Opera just hangs up, it dies!
More like Opera doesn't really "like" the code there or something.

Can't be Javascript, as I can turn it off, and it won't do anything.

Umm. How much RAM does the server have now? I only have a VServer, also WINDOWS with only 512 MB ram, lol. A while after I rented it they changed their offer to 1024 MB ram.

Currently gelbooru has 12GB. We can upgrade it to 24GB using 4GB sticks. Of course 6 4GB sticks will cost nearly 250 a piece. (Cheaper to buy a new motherboard and more 2GB sticks)

Well, man. Why 250 $ just one stick of ram? Server RAM costs THAT much? I thought it's only normal DDR-2 or DDR-3 RAM, where DDR-2 costs like 40 or 50 if you buy the best ones.

Need to use FB-DIMM ECC type RAM. Much more expensive. DDR 667. The only way to go past the 8GB limit, I believe, is to use registered fully buffered type.

www.newegg.com/Product/Product.aspx?Item=N82E16820134629
www.newegg.com/Product/Product.aspx?Item=N82E16820134620

What are you using all of that memory for? It seems like access on these sites is typically heavy access for the first few pages (cacheable), and then random access throughout the site from searching (not very cacheable). Once there's enough memory to cache the initial active pages, and enough to keep the database indexes in cache, I'm not sure where adding more would help.

moe.imouto.org is running off 2GB, and that system stays responsive even when the site peaks at 6-8 megs/sec. If you're caching all of the thumbs, that's only maybe 4-5 gigs (not a very scalable optimization, though).

In any case, gelbooru is always pretty fast for me, so I'm not sure what the issue is. It's not nearly as fast as it used to be, though; I got 700-800k/sec when it was on FDC, but steadfast.net is only a mediocre 150-200k/sec.

I'm putting thumbnails on a virtual RAM disk, and if I put more RAM in, I can put all the other expendable cache on there as well increasing read performance over 50X, making the site's pages load even faster than before. Our page cache and search cache reaches about 5GB every 5 hours.

As for Moe, they have 22k pictures compared to our 300K and page views are half as much. Once you hit a large amount of thumbnail loading, getting disk queues of 600 (while using multiple domains to serve thumbs), then you'll see why RAM can be a nice thing to have. Yeah, it's a lot, but it's worth every penny.

The search cache is very cachable as it doesn't change as often as you think. The main page, when it shows every image, does not cache for it changes too often to be effective.

We have other services on here that eat up RAM like candy, and we have our RAM drive set up at 7GB. Currently 2.33GB is free. This will be nearly nothing in a few months. Tons of RAM on a webserver doing multiple roles will only make doing stuff on it that much easier. I'm sorry to hear steadfast is slower for you, but I hope that 200KB is enough to view the majority of images here quickly. I was getting complaints with FDC being slow.

Adding memory isn't likely to be an optimization that scales very well--which is what you're seeing, of course, with further upgrade costs rising so much.

Are you putting thumbs and images on separate drives? Offloading the seek-heavy thumbnails would avoid competing with the image serving, and adding more drives should scale linearly: just split the thumbs across them evenly, on the image hash. (How far that scales depends on how many drives you can add, but drives need to scale with traffic, unlike RAM, which has to scale with the number of images.)



You mean people search for the same stuff often enough that caching random images is actually useful?



That's odd; I've never seen any complaints of moe being slow. (It's complicated a bit by the mirror, which is a bit slow for me, but faster for EU folks.)

By the way, this cramped little input box could be twice as big or so ...

Yes, thumbnails and the large images are being served off different drives. The rate that the thumbnails are requested, 100 requests/second, is a bit too much for those moving parts (Min 300 files/s Max 6,000 files/s). Larger files seem to have an easier time being read quickly as it's only 1 request rather than 15 at once.

The larger images are split across multiple drives and domains which will be merged into just one domain sometime in the future.

I should explain what the types of caching we do. We do caching of the 'page=post&s=view' and any tag searches you perform. Imagine if 1,000 people decided to search Loli. That's something MySQL would groan about, peaking CPU usage up there for a moment while it serves from the cache it created. Just saving the results you got in a static HTML file would be better as it won't need to make an SQL connection or anything, unless the file/folder doesn't exist.

Now, if you click and view an image, the comments are forced to be loaded every time. The page view cache is not quite as beneficial as caching the search results, but it still reduces load enough to be feasible. By caching the viewed images, we are then able to avoid seeking of the comment table, ratings, tags, and what ever else is there, and just serve a static document to you.

While we may have 8 cores, it's nice to be under 30% all time time to do other things with the hardware.