[QUOTE=NBtarheel_33;379128]Wow, yeah, we *are* getting to the point where a smartphone would be more powerful.

Trying to surf the Internet or even run Windows or Office with 2GB of RAM would be quite a feat these days.[/QUOTE]

Dual Core Xeons @ 3ish GHz with DDR2-800MHz memory. Yikes.

Well, there is something to be said about how things in the goode olde days were built. A 2014 server built on 2006 hardware and only now is showing its age.

[QUOTE=TheMawn;379177]Dual Core Xeons @ 3ish GHz with DDR2-800MHz memory. Yikes.

Well, there is something to be said about how things in the goode olde days were built. A 2014 server built on 2006 hardware and only now is showing its age.[/QUOTE]

Those DL360 G4p machines were pretty good for their day. At my last gig I managed quite a few of those (and DL380's) and I'm sure some of them are probably still running there. They were pretty solid for sure, just getting long in the tooth.

[QUOTE=Prime95;379135]All useless without Scott's time to oversee transferring the databases to a new machine. BTW, we already have a volunteer offering a drives, RAM, or newer model.[/QUOTE]

Absolutely no disrespect intended, but why is Scott in the critical path?

Clearly things are not working well currently. Perhaps it's time for new modern hardware (which has been volunteered) and "new blood" (which has also been volunteered).

Just saying....

[QUOTE=chalsall;379225]Absolutely no disrespect intended, but why is Scott in the critical path?

Clearly things are not working well currently. Perhaps it's time for new modern hardware (which has been volunteered) and "new blood" (which has also been volunteered).

Just saying....[/QUOTE]

I was curious myself and traced where the [url]www.mersenne.org[/url] server lives... it's in San Diego, where Scott hangs his hat too, hosted in an I2B Networks collocation. I'm presuming Scott pays the bill for that which is cool. I hope he gets donations because even a 1U server with power/network isn't all that cheap.

George is the guy who gets the fun of fussing with the server and tweaking it, but I'd guess that physical access to the system itself comes down to Scott.

Perhaps if Scott and George were amenable to it, an alternate location or at least an alternate contact in the San Diego area from out of the Primenet/GIMPS fans could be setup with access to I2B or to assist in server maintenance remotely, but I won't presume to suggest they *should*, just that I'm sure there are many folks willing to pitch in. After all, there could be times when Scott and/or George are on vacation or just plain unavailable to deal with server issues.

For example, I'm the only server admin in my team but when I take a vacation, I *have to* pass the baton to someone else in a similar role in another department... it's the anti-SPOF thing to do (SPOF = single point of failure... in my case, it's me :smile: ).

The infamous [URL="http://en.wikipedia.org/wiki/Bus_factor"]truck factor[/URL] ~= 2 here.

[QUOTE=Batalov;379240]The infamous [URL="http://en.wikipedia.org/wiki/Bus_factor"]truck factor[/URL] ~= 2 here.[/QUOTE]

We used to joke about "what if you get hit by a bus", and then one day a couple years ago, one of the other admins here actually did get hit...well, not a truck or bus but a car, riding his bike to work. Banged up but okay, and yeah, those kinds of things get the management folks concerned about making sure knowledge is shared, roles are shared, etc.

Primenet isn't one of those things where if it were down for a while, money is being lost or productivity goes down the tubes, but I like the idea of backups for George and Scott. They're irreplaceable of course for all the work they've done and still do, but I say if George had someone taking care of the drudge work of maintaining a web/SQL server, he could focus like a laser on tweaking extra milliseconds of performance from the latest CPU/GPU.

Of course maybe he likes learning about SQL and the tuning that goes into it... learning new stuff can be fun. :smile:

[QUOTE=chalsall;379225]why is Scott in the critical path?[/QUOTE]

Madpoo got it right. Scott and the server are in San Diego. I'm in N.C.

[QUOTE=Madpoo;379242]Of course maybe he likes learning about SQL and the tuning that goes into it... learning new stuff can be fun. :smile:[/QUOTE]

Back in the day, I made a living knowing the ins and outs of SQL. Our company played a significant role in the development of ODBC. At the time, Sybase, SQLServer's predecessor, was among my least favorite databases.

Database admin is a different beast. Learning new stuff can be fun, the jury is still out as to whether learning SQLServer admin or later on Linux/MySql admin will be fun.

I agree that getting the truck factor above two is a good goal. I tried to shame James into becoming a backup, but apparently the spectre of learning Windows and SQLServer was too much for a sane human being to bear.

Out of morbid curiosity (I do this on my own websites too), I did some performance analysis of the [url]www.mersenne.org[/url] homepage, and just from a web hosting point of view, there's probably some easy pickin's to get things going a little better.

1) There's a call to an image /images/SBSI_logo_2008.gif that's a large, ugly, animated GIF (153 KB). What's stranger, the link when clicked on is a holding page ("Web Page Under Construction"). Doesn't seem like the best use of 153 KB of download... over half of the total data on the home page. At least the server says it's cacheable for 1 week, but even that could be higher if it's really needed.

2) HTML isn't compressed by the server... just on the base page text/html, compressing it would take it from 26,363 bytes to around 8,661 or so. The CSS and JS could be compressed too. Given the server's vintage, using compression could increase the CPU usage too much, and I don't think IIS 5.0 (Windows 2000) has the same settings to tell it to stop compressing content if CPU usage gets too high. IIS will at least cache a compressed version of any static resources so it probably wouldn't really hurt, but hard to say.

3) The Google Analytics script isn't using the async script. Well, it's using "ga.js" which is the async version, but the way it's loaded isn't using the async method. It's an easy enough fix.

4) There's a counter being loaded from counter.digits.com that was frequently behaving pretty slow, at least when I tested. The counter at the bottom of pages is so 20th century anyway. :)

5) There are some other links at the bottom with images, "badges" I tihnk they're called, like Cool Site of the Day and Safe Surf. These are nothing more than old attempts at link boosting. If it were me I'd remove them, but if they really had to be there, make sure to add a nofollow so the page doesn't get penalized for link spamming.

6) There's really not enough static resources (images, scripts, css) to warrant a CDN, but thought I'd mention it.

7) The expirations of static items is just 1 week... if they're unlikely to be updated often, I recommend a 1-year expiration. If they ever do change, my strategy is to add version strings as a query parameter, like /2013/style.css?v=1.2, but then you need a system in place to make sure code is updated with new version strings whenever a new static resource is updated... if it's being built and deployed, that can be automated, or if updates are infrequent enough, doing it manually isn't a hassle as long as pages are templated. Even a search/replace to update the version strings is an easy approach.

8) I'm getting nitpicky, but the jquery.min.js is loading from the Google CDN. That's perfectly fine in the US, but I manage international websites and found that the Google CDN is horribly slow in Asia, Australia, South America, etc. Europe and North America they're about even, but if the audience is truly global, the Microsoft CDN is a better all around performer.

9) In general though, the page just loads slow because of back end work being done to load the page. On the home page it's not bad... there's some stuff in the left column showing daily stats ("Today's Numbers") but maybe that's only generated a few times per day, not in real time. But I was getting times of 1-2 seconds for the "time to first byte" which is pretty slow. That's my browser waiting for a response from the server.

I almost missed one of the more obvious things... the Google Translate button up in the top right. :) Chrome offers to translate a page if it's not in your native language, so buttons like that are increasingly less useful I guess.

It doesn't hurt *too much* having it there, except it brings in it's own CSS (on an encrypted connection too) which might slow down the time when the page starts to render. At least it looked that way on my waterfall chart. I could be wrong. But that SSL connection to get the Google translate CSS... ick. SSL is great if you're passing data that should be encrypted, but Google's push to encrypt everything means slow initial connections... can't say I'm exactly on board, at least until SPDY / HTTP 2.0 gets further along, which can make up for those initial delays.

[QUOTE=Madpoo;379268]…me offers to translate a page if it's not in your native language, so buttons like that are increasingly less useful I guess.

It doesn't hurt *too much* having it there…[/QUOTE]

All of that was pretty amazing, one of the better more educational posts I have ever seen on this board. I haven't been here long.

I would like to thank you for doing that if only for me to have the chance to read it.

Double plus good.