On Wed, Nov 4, 2009 at 6:47 AM, Mikhail Kryshen <mikh...@kryshen.net> wrote:
> On Tue, 3 Nov 2009 16:34:57 -0800 > Costin Manolache <cos...@gmail.com> wrote: > > > Curious: how does it scale for large number of users, in particular if > you > > have NFS homes ? > > I use it at a university server with 780 user accounts with home > directories mounted via NFS from distinct file server, user database is > LDAP. Reading the remote user database and checking all home directories > for webapps takes about 100 ms of real time. > > I was asking about tomcat startup time - loading all the 780 contexts, versus a normal startup with 2-3 contexts. BTW - it would be nice to include this kind of info in the docs. > Performance for the large number of deployed webapps would likely be the > same as with the original tomcat UserConfig or Host having all the apps > in a single appbase. > > > It would be interesting to change this to not init the contexts when > tomcat > > starts - just register a handler that would start the context on first > > request. > > Or as a Valve that looks for ~foo and then lookups and start the context > for > > that user on demand. > > Most contexts will probably start soon anyway since every user would want > to check his/her webapp after it is installed. Then to make this approach > useful some checking for long-ununsed contexts would be required or > periodic tomcat restarts to clean-up. Anyway it would be interesting > thing to implement. > 780 users each accessing his app every time tomcat starts ? I doubt it. You're right, stopping long-unused contexts would be another nice thing. > > > IMHO this could be a nice feature - but it's a perfect example of thing > that > > shouldn't be bundled in tomcat, but > > available as a separate download. And if it used a scheme like /user/foo > - > > it may even be possible to implement it as a app+standard filter, with > just > > one 'internal API' call to load the context. > > For me it's not a problem to support this as a separate package, but > tomcat already have such a thing bundled which is not currently very > useful. Well, since we'll have a major release - it is possible to move what used to be bundled ( and not currently very useful or used by lots of people ) to separate packages that can be better supported. Costin
