Gavin McDonald wrote:
From: Andrea Pescetti
On 29/11/2011 Rob Weir wrote:
==Option 1: Remain at OSUOSL==
We could remain with OSUOSL hosting. However, the existing site is
very unstable.
This would be best both for short and long term. ...
Sorry, OSUOSL don’t want anything to do with these any longer
As I wrote, Options 1 and 3 (i.e., staying with OSUOSL or cloning to
another host) are fundamentally equivalent to me. My point is that the
best first step is starting from the current websites or a clone of them.
The hosts themselves cannot cope with all the
memory and cpu these are consuming all the time, let alone the bandwidth.
Then someone should explain why they were absolutely stable in 2010,
with a traffic that can be safely assumed to be similar to the one they
are receiving in 2011. Something broke, and since the Drupal code hasn't
changed I still think that the malfunctioning components are somewhere
else (or, if in Drupal, not in the site itself but in the interface to
caching engines).
I've had a look around
the drupal sites and it is not optimal to say the least.
It would be helpful to know what level of access you obtained to make
this assessment. Could you read the site code, or did you receive
administrator credentials for the website, or did you get shell access
to the machine?
That the sites are not optimal is fairly obvious, especially considering
that Extensions is a Drupal 5 site and thus creates sessions even for
anonymous users; Drupal 7 is much better in this respect and offers more
scalability out of the box and better integration with caching engines,
so it seems a natural candidate for medium-term and long-term
improvements ("Option 5").
==Option 2: Move Critical extensions to stable host==
Indeed, as you write, this would be an extreme option.
More extreme would be to do nothing, as you'll end up with nothing.
Of course. What I meant to say was: cherry-picking "important"
extensions and creating a repository for them from scratch is more or
less the same work of Option 1 or 3 (i.e., fix the current site or a
clone of it) for a much less interesting result.
==Option 3: Clone OSUOSL repositories to another host==
This is not significantly different from Option 1; i.e., if there are other
hosting
options available the mere cloning of the site would not take long, but again
the problem is not with the site but with caching.
Do not blame caches for poor performance. the caches are improving a bad
situation
OK, no matter what we think about the root cause for the current bad
performance it seems that we both agree that cloning the site will give
us the possibility to tweak it (or the environment) and improve
performance. Since I've seen it working perfectly in 2010, I'm confident
this is achievable.
==Option 4: Host repositories elsewhere, using new UI==
As I used to say, everybody who thinks that the Extensions or Templates
sites can be replaced easily has never tried submitting a template!
Thorsten did a lot of customization work on the two sites; any replacement
would provide a largely inferior user experience.
I think you don’t think very highly of other peoples abilities, a poor outlook.
That was just a warning: people should know (and they would know, if
they had ever uploaded a template...) that the sites extract and use a
lot of information specific to OpenOffice.org and ODF files. This is
often overlooked when people see these sites as "some form of file
repositories" and propose to rely on different solutions: they should be
aware that, to provide an optimal user experience for our use case, a
significant amount of custom code must be added.
==Option 5: Re-architect the Repositories== This is the option I
personally favor for long term. ...
OK, it seems we have agreement, at least at broad scope, that the
long-term solution will be along the lines of Option 5 (i.e., encourage
or enforce external hosting; allow for a scenario involving several
different repositories).
here is the route I intend to take:
1. Move the services to a newer more modern host at the ASF (temporary)
2. BandAid the installation to stabilise it for the short term (this is still
more work than it sounds)
So it seems we agree on these steps, and it's great (for planning Step
1) that you have access to information that is not available to me.
3. Stick Apache TrafficServer in front (not varnish) to improve response times
/ caching.
I don't have enough knowledge on Apache TrafficServer to comment on this
specific step.
4. Go with the choice of Option 5. that is, to allow the hosting and
downloading of the templates
and extensions to be with the 3rd party authors.
It's already allowed; it is just not enforced. I mean, it already
happens that some extensions form the Extensions site are downloaded
from external sites like SourceForge.
the status quo can not continue, for benefit of all.
Help welcomed at any step of the way.
Just make sure to get permission to transfer and modify the site code
from Oracle, or clarify that such a permission is not needed. I can't
have any active involvement with this until this issue is solved, even
though I completely share your desire to bring the sites back to normal
operations as soon as possible.
Regards,
Andrea.
