I think many issues or questions also are result of defaults in Aolserver and Naviserver still being set according to past AOL setup and requirements. It can be considered as an extreme case and because a lot of functionality was implemented for AOL high-performance requirements and setup, everybody else has to know that deeply, change config and/or know C code good enough to make knowledgeable decisions.
For example, one of such things is threaded allocator which is default in Tcl, nowadays default allocators a good enough, return memory to the system, zippy is needed only in very high performance cases and even in such cases it needs carefull testing to make sure the application does not consume more and more different pieces of memory which will lead to even wore fragmentation. I always recompile Tcl with default memory allocator: it has 2 benefits, 1) not-ever-growing, 2) i can use vtmalloc easily for example if default one does not work like i need We know the code and we assume everybody else should and many questions and problems reported seem like dumb or idiotic but they are not in all cases. I think all functionality AOL developed is very valuable but enabling it by default is making everybody else to follow AOL's way of doing things with AS/NS. Jeff Rogers wrote: > Brett Schwarz wrote: >> Wow, I am amazed at the different reactions to this issue between >> this list and the aolserver list. Makes me want to switch to >> naviserver even more now... > > 90% of the difference is that the issue was introduced here by someone > saying "I contributed a patch." That in itself gets a better reaction > than hyperbole and insisting that everyone else doesn't know what > they're talking about. On the flipside, some of the reactions were > overly harsh and dismissive. > > BTW, the solution in the patch of adding the filename to the hash key > was rejected by the OP. > > After all the discussion there, I am generally in agreement that there > is no real problem other than insufficient documentation, caveats, and > examples. But some options to make the cache less aggressive when > necessary can be a good thing. Other than adding in the filename (which > causes more memory to be used) a way to avoid the caching in the first > place could be good; either a -nocache flag to ns_returnfile or a > different command (to still get the performance of mmap-ing) or my other > suggestion of skipping caching for files matching certain patterns > (e.g., under a particular directory like /tmp, /var/tmp, or whatever) > would avoid uselessly using up the cache memory in the first place. > > As far as the performance impact (of mmap or fastpath in the first > place) numbers speak louder than speculation, and testing it isn't that > hard. > > > -J > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
