[TYPO3-doc] Documentation servers

Fabien Udriot fabien.udriot at ecodev.ch
Sat Sep 29 11:11:45 CEST 2012


Hello,

Is the rendering that (over)loading? ReST rendering is more lightweight in term of resource than the
previous XSLT rendering we had. We could also make the process "nicer" so that it does not consume
and monopolize all the memory / processor. Having two servers may sound as a more flexible approach
in term of architecture design but has more complexity as you pointed out. The bottom line, is that
I am not opposed two have two machines (rendering and delivery) but perhaps consider it as a nice to
have and based on the experience we need one. As a first step, I would "work" on the same instance
but nevertheless develop things to be *decoupled* in case we need to separate the service.

> - 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.

For me srv123 was a testing server where we can experiment and play around without worries. srv130
would be the "true" one which renders the documentation and is set up by Chef (which is currently
the case). At one point, srv123 would be erased and set up again with an image of srv130. If we
decide to go from the start with two separate rendering / delivery servers, then we would set up a
new one.

> 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 ...
> - have some form of messaging for one server to inform the other.

I think solution 1 (use the same DB) is the easiest as a first step.

About the communication btw the rendering and delivery server, there was the idea of Steffen Gebert
to use beanstalkd as a central place within our infrastructure. In this regard, the rendering
service would post a message (in the queue) that is going to trigger the sync by the delivery
service. Is this vision still valid?

https://notes.typo3.org/p/beanstalkd

Fb.


More information about the TYPO3-project-documentation mailing list