FreeBSD svnweb server down?

https://svnweb.freebsd.org has been returning errors like nginx "504 Gateway Time-out" / "Error 503 Backend fetch failed", etc. for over 24 hours now. I'm not sure where to address a problem report about that - can someone from "the management" here pass it along to the appropriate people? Parts of it are still in cache somewhere, so the URL I gave at the beginning of this post will appear to work, but drill down and you'll eventually get an error.
 
Are you still getting the error? It seems to work now, I did have the occasional gateway time-out in the last few days.

Edit: When browsing around it does feel rather slow and it does look like it has some issues fetching data from the backend(s).
 
Are you still getting the error? It seems to work now, I did have the occasional gateway time-out in the last few days.

Edit: When browsing around it does feel rather slow and it does look like it has some issues fetching data from the backend(s).
It is better than it was, but still has the occasional hiccup - for example, https://svnweb.freebsd.org/base?view=revision&revision=346511 is giving me 503's now. I've always found it slow (compared to the old CVS one) but chalked that up to the higher complexity of SVN vs. CVS and possibly fewer back-end resources (there were a lot of public CVS mirrors - I had one for my company, for example). But it has been getting slower and slower over time. Can someone check and see if the hardware has problems and if more / faster hardware might be needed?
 
I can't comment about the hardware, but the site is snappy for me. Actually, not trying to be a contrarian, but I'd say it's faster than in the past .. for me at least.
 
I can't comment about the hardware, but the site is snappy for me. Actually, not trying to be a contrarian, but I'd say it's faster than in the past .. for me at least.
The link in my reply now displays correctly instead of 503-ing. However, drilling down to the next level 503's again. It seems like it takes a random interval from minutes to an hour or so to fill old requests into the cache.

It is quite snappy if you're looking at stuff in the front-end cache. But request anything from the actual back-end and it takes unreasonably long, particularly with the 503's now.
 
It is ok again. But for 5 hours no chance. I could reach all other sides except all from freebsd.org.
And is now broken again.

FWIW, I provide (unpaid) porting assistance to a number of vendors supplying commercial software for FreeBSD. FreeBSD is a very small percentage of their sales, but I try to do my part to increase the visibility of FreeBSD. I use svnweb.freebsd.org to research things when providing the aformentioned porting assistance. I've had to cover a number of times now, saying "I'm working offsite, I'll get back to you in a day or two" because saying "sorry, the page I use at freebsd.org to research your issues is usually broken" would not inspire confidence on their part. Hopefully those vendors don't read this forum. :rolleyes:

Seriously, can someone ask "the management" (or, who even knows who "the management" is) to get this looked at and fixed? If the issue is throwing more hardware / money / volunteer time at the problem, then please let us know here exactly what is needed.
 
There are some complicated infrastructure migration happening, and I think that not finished yet. It is being done slowly to avoid to have problems everywhere.

Sorry for the inconvenience. :)
 
There are some complicated infrastructure migration happening, and I think that not finished yet. It is being done slowly to avoid to have problems everywhere.
As long as everyone is sure that that is what is causing it. I'd hate to have the migration continue and be announced as successfully completed, and then still have the same problem. I'm in the ISP business, and I've learned to never take "X is due to Y" from an upstream without verifying, nor to do the same to one of my customers without verifying.
 
This is easy to know. You move to some new server and then some things are not working, you moved back find the issue in the new setup and fix that. :)
 
This is easy to know. You move to some new server and then some things are not working, you moved back find the issue in the new setup and fix that. :)
Or moving exposes some unrelated problem which was hidden for some unknown reason.

The reason for my reply was not to sound snarky, but because in prior replies to this thread some users have said "working fine here" (where "here" is likely some different geographic region, possibly served by a different host system). If that was indeed the case, the issue might be an overloaded (or in the process of moving) back-end server or the front-end server, and the problem could be reduced by pointing the DNS records for the front-end or the back-end that the front-end uses temporarily to some other server, perhaps in a different region, that is not in the process of being migrated at the present time.
 
Apparently, the new setup is getting some design improvements. It is not exactly a clone/1x1 migration path.
(I am not involved on the migration at all and so IDK about the details of what is going on and how)
 
Back
Top