[TYPO3-doc] Documentation servers

[Steffen Gebert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Francois,

we came up with the idea to have a separate rendering server to prevent
things like on the old typo3.org server, which was down every day for
30min because of high manual rendering load (everything was rendered
every day.. yes.. not so clever ;-)).

I'm also still in favor of this idea.

To prevent things like sharing database or file systems, I would highly
appreciate the ability to use the rendering server as a service.

I imagine sth. like POSTing a zip file, which then triggers the
rendering mechanism. The result is returned back.

Further ideas would be:
* POST a URL of a zip file or a git repo (+revision) to render
* return back a link to the result file
* provide a web site, where people can submit their ZIP files to get
them rendered and returned (+ shown online?)

Mechanisms to protect the infrastructure
* queue up rendering to ~two processes per IP
* ..?

What do you think?

Kind regards
Steffen

- -- 
Steffen Gebert
TYPO3 v4 Core Team Member
TYPO3 Server Administration Team Member

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

I work for TYPO3 solely in my spare time. If you think that
my work helps you running your business, you are invited to
send me a donation via PayPal to this email address. Thanks

On 9/28/12 12:14 PM, François Suter wrote:
> Hi all,
> 
> Yesterday with Martin we discussed our current server setup and how it
> should work in the future. This is what we currently have:
> 
> - srv123.typo3.org (a.k.a. preview.docs.typo3.org) is currently used for
> everything, rendering the documentation and serving it too.
> - srv130.typo3.org (a.k.a. docs.typo3.org) is supposed to be the "final"
> docs server.
> 
> That's where opinions diverge. In my vision, srv123 becomes the
> rendering server. Its only mission in life is to receive rendering
> requests and perform them. srv130 OTOH has only one goal: to server
> documentation pages.
> 
> The advantage of this separation is that srv130 never runs the risk of
> being slow (or even down) if some documentation rendering task takes a
> huge load (for example, upon a TYPO3 release, with all the sysext
> manuals, plus official manuals following up).
> 
> The disadvantage, of course, is that srv123 needs to post its stuff to
> srv130 after rendering. We need a way to make that efficient. I would
> say rsync should be quite fine for such a job.
> 
> We also need to consider database issues. We plan to have the FLOW3
> application that coordinates the whole show create database entries for
> each manual/version/language combo. If the rendering happens on srv123
> that entry will be created there, but srv130 needs to be aware of it
> too. There are several solutions:
> 
> - use the same DB (e.g. srv123 accesses the DB on srv130)
> - use MySQL's replication tools (which may be tricky if srv130 starts
> collecting data too in the future, for example comments)
> - have some form of messaging for one server to inform the other.
> 
> Your opinions are very welcome.
> 
> Cheers
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZcjKAAoJEIskG/rSlyw4/8IIAMurnmYYIYmXGrC+O1E4UvO9
laIlFohAT8IZLY6wtZvo760FRdIojPJQjZYBrvIMN630xSp8rG/6gWUwKAsip0pG
BD9drUXZuF1R6920z5X95+qd/588I07IbqSCBfIL0cj72lfxBP3ri16JaWAVRvuT
vTjnsC5u9mQeNid/gknsZ1u1iVePCEStTWxZqfXuSx5azTN+ZfgxhzM/q9pmraaw
0eygLrLp91EVOWNYpKzn2+JpT2GDukFXr4imf/cONdYlXoLMaCIOLsxcHD/EkJPz
WlmtCW/2lSITK5l81DZNGyuCAp0sCqBVbojVCyUOStBvXTlGvplfyLGfWHQ+F14=
=tk8i
-----END PGP SIGNATURE-----