You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: amm [Submitted to the original trac issue database at 9.23am, Monday, 29th June 2009]
The following patch is thought mostly as a request for comments. Although it seems to work fine locally, it is only lightly tested and presumably is still missing some corner (error) cases.
Currently mod_tile driven renderd can only use a single render server. It might however be useful to use several servers to achieve higher performance. The attached patch allows you to do this. It has one master renderd that talks to mod_tile and can have several slave renderd's that may be on different machines as long as they can access a common filesystem for tile storage.
The way it works is that the master renderd has a bunch of extra render threads, one per slave render thread, however rather than rendering it it self, it simply passes it on to the slave process. As only as many requests get passed on to the slave as there are rendering threads available, these always get rendered immediately, thus keeping a centralised queue. The slaves are unchanged other than that they now take requests over TCP/IP sockets rather than unix sockets.
Any suggestions or comments if this patch is useful or on its style are welcome.
The text was updated successfully, but these errors were encountered:
Reporter: amm
[Submitted to the original trac issue database at 9.23am, Monday, 29th June 2009]
The following patch is thought mostly as a request for comments. Although it seems to work fine locally, it is only lightly tested and presumably is still missing some corner (error) cases.
Currently mod_tile driven renderd can only use a single render server. It might however be useful to use several servers to achieve higher performance. The attached patch allows you to do this. It has one master renderd that talks to mod_tile and can have several slave renderd's that may be on different machines as long as they can access a common filesystem for tile storage.
The way it works is that the master renderd has a bunch of extra render threads, one per slave render thread, however rather than rendering it it self, it simply passes it on to the slave process. As only as many requests get passed on to the slave as there are rendering threads available, these always get rendered immediately, thus keeping a centralised queue. The slaves are unchanged other than that they now take requests over TCP/IP sockets rather than unix sockets.
Any suggestions or comments if this patch is useful or on its style are welcome.
The text was updated successfully, but these errors were encountered: