Hi Christian, *
No, on the contrary, especially because it is run on so many servers
with limited resources, I'm not willing to waste RAM on pootle-VM
alone, when pootle doesn't need it at all.
Please leave the technical discussion aside for a minute.
What *we* as a team of localizers need is a working and performant
setup to do our translation work. All data that you retreaved from
the brazilian pootle server are just peanuts and not relevant for
what we need to have in the next few weeks for several reasons:
- we had no full localization on the server (but we will have to provide
this for 3.4 localization)
- hardly any team did full translation on the server, we "only" did
bugfixes
There were some good reasons to have a rather good equipped server for
pootle. We knew, that pootle might be not the perfect solution regarding
memory usage, multithreading ... That we now cannot use the initialy
planned setup is very unfortunate. But we still need a system that
provides similar performance.
I clearly explained why I'm convinced that it is a memory leak. It
doesn't free the memory, even when the machine is idling for hours. It
doesn't need that memory, since when the worker is replaced by a fresh
one, the functionality still works.
No - it is just that this is totally irrelevant in the current situation.
Even if pootle has a memory leak, we won't fix this within the next few
days. But we need to start translating asap!
So - if there is any way to provide more ressources (memory) we should do
this and analyze the root cause later (I'm sure, pootle developers are
interested to help with this).
Again:
* I don't have a problem with pootle taking half a day to import the
files for a new release (one time thing, no big deal)
* I don't have a problem with pootle taking very long for the very
first hit of the frontpage after a reboot (system is not rebooted that
often, also no big deal)
* I don't have a problem with restarting pootle server-processes to
workaround the memory-leak (whether you call it leak or not, I
definitely call it leak). It limits the amount of concurrent worker
processes, but that is not a problem since even with just the two as
in the VM, you can easily serve 50 concurrent requests per second
while benchmarking (resulting in being able to handle about 200
request/second of the frontpage, thus much reserves available. No
problem)
Maybe you don't have, but the translators will have a problem with this.
So either we can provide more ressources to the VM or we need a
different solution.
All other discussion is very academic at the moment.
regards,
André
--
Unsubscribe instructions: E-mail to l10n+help@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/l10n/
All messages sent to this list will be publicly archived and cannot be deleted
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.