incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Registration and Update Services - What Will Be The Load?
Date Wed, 15 Aug 2012 21:49:55 GMT

On Aug 15, 2012, at 2:29 PM, Kay Schenk wrote:

> On Wed, Aug 15, 2012 at 11:15 AM, Rob Weir <robweir@apache.org> wrote:
> 
>> On Wed, Aug 15, 2012 at 2:05 PM, Dave Fisher <dave2wave@comcast.net>
>> wrote:
>>> 
>>> On Aug 15, 2012, at 10:28 AM, Daniel Shahaf wrote:
>>> 
>>>> Rob Weir wrote on Wed, Aug 15, 2012 at 13:11:43 -0400:
>>>>> On Wed, Aug 15, 2012 at 1:05 PM, Daniel Shahaf <d.s@daniel.shahaf.name>
>> wrote:
>>>>>> Oliver-Rainer Wittmann wrote on Wed, Aug 15, 2012 at 16:32:21 +0200:
>>>>>>> Is it possible that somebody from the Apache Infrastructure can
>>>>>>> provide a view on which URL the traffic load was soo high that
the
>>>>>>> servers got in trouble?
>>>>>>> 
>>>>>> 
>>>>>> POST requests to /ProductUpdateService/check.Update file
>>>>>> 
>>>>> 
>>>>> For which subdomain, which UpdateXX.openoffice.org ?
>>>> 
>>>> The access log doesn't say, and the error log has
>>>> 
>>>> % fgrep /ProductUpdateService/check.Update error_log | sed -e
>> 's#^.*/content/projects/##' | cut -d/ -f1 | sort | uniq -c
>>>> 
>>>> EU:
>>>> 232046 update30
>>>> 35548 update34
>>>> 76543 update35
>>>> 
>>>> 
>>>> US:
>>>> 198996 update30
>>>> 33450 update34
>>>> 71117 update35
>>>>  0 update36
>>> 
>>> We don't see update32 because those do not get redirected in the same
>> way because there is no ooo-site/trunk/content/projects/update32
>> 
> 
> uh oh...this should have been setup before  and Oliver said he requested
> this in the first post here.
> 
> And you're now saying that all the previous ones have been reverted?

The zone file is now:

; update.services               CNAME     www.openoffice.org.




; WARNING WARNING WARNING
; Changing the above entries to point to eos can overload it.  Do not enable
; them unless either eos is prepared for the load or the TTL is suitably
; lowered
update.services               CNAME     sd-web4.staroffice.de.
update23.services             CNAME     sd-web2.staroffice.de.
update24.services             CNAME     sd-web2.staroffice.de.
update30.services             CNAME     sd-web2.staroffice.de.
update31.services             CNAME     sd-web2.staroffice.de.
update32.services             CNAME     sd-web2.staroffice.de.
update33.services             CNAME     sd-web2.staroffice.de.




update34.services             CNAME     www.openoffice.org.
update35.services             CNAME     www.openoffice.org.
update36.services             CNAME     www.openoffice.org.
update38.services             CNAME     www.openoffice.org.


> 
> I think we were OK until this last one, right? update32?

Only yesterday's changes to DNS were reverted.

> 
> I think the others should be re-established as they weren't causing
> problems, were they?
> 
> The thing is unless we go back to the code for OOo 3.1, we don't know what
> it's doing.
> 
> When I asked about this when we had issues for OOo 3.0, I was told it was
> fixed in OOo 3.2, so maybe 3.1. has the same issues?
> 
> 
> 
>> 
>>> ./update/aoo341/check.Update
>>> ./update/ProductUpdateService/check.Update
>>> ./update30/ProductUpdateService/check.Update
>>> ./update34/ProductUpdateService/check.Update
>>> ./update34/ProductUpdateService/test.Update
>>> ./update35/ProductUpdateService/check.Update
>>> ./update35/ProductUpdateService/test.Update
>>> ./update36/ProductUpdateService/check.Update
>>> ./update38/ProductUpdateService/check.Update
>>> 
>>> It looks like 34 and 35 have been trouble, but not as bad as 30.
>>> 
>> 
>> But haven't 34 and 35 been in production since early July?  We've
>> certainly seen plenty of downloads triggered by them.  They should not
>> be giving any errors, since the requests resolve to files on our site.
>> 
>> I wonder, could the errors in those be caused by the outage caused by
>> the errors in update30?
>> 
> 
> Rob...update 30  is completely out of the question, and we simply can not
> do it, and reverted it within hours when I first requested it.
> 
> There IS an update30 directory there but it isn't actually being used, and
> is just a dummy file anyway. Maybe we should just delete this one  so we
> won't get confused about this one anymore. It was setup in early stages of
> testing.
> 
> Should I just delete ./update30/ProductUpdateService/check.Update -- I mean
> the whole directory.
> 
> 
>> -Rob
>> 
>>> Regards,
>>> Dave
>> 
> 
> 
> 
> -- 
> ----------------------------------------------------------------------------------------
> MzK
> 
> "Never express yourself more clearly than you are able to think."
>                                                                        --
> Niels Bohr


Mime
View raw message