For what it's worth, we have a pure MarkLogic application behind nginx functioning as a reverse and caching proxy. Performance has been improved manifold. This application is mainly read-often write-rarely so caching pages makes sense. Tests without the caching proxy of our Standard License installation on a single core virtual machine running Windows 2008 R2 had previously shown that this specific environment would not have been able to serve requests quickly enough. Good to know: We were able to add nginx at the very end of the development without having to make any changes to the application.
cheers, Jakob. On Fri, Jan 27, 2012 at 18:36, Michael Blakeley <[email protected]> wrote: > I would probably go ahead and develop the prototype without an extra http > layer. If and when you need it, it isn't so difficult to add. > > Using something like apache, nginx, or lighttpd gives you extra flexibility, > either via virtual hosting or using reverse proxy configurations. Whether you > really need that extra flexibility is application-specific. > > But I think the main thing that might drive you to add a front-end httpd > would be concurrent load: hundreds or thousands of concurrent requests, where > many of them are for static resources. The nginx server has been shown to > handle thousands of concurrent connections well. A MarkLogic http server > defaults to 32 threads, plus a backlog queue that defaults to 256. Both of > those values can be increased, but I don't know if anyone has ever tested the > behavior with thousands of concurrent connections. For a prototype and for > most web applications that does not matter, but if you were deploying a > mass-appeal web site then it might. > > -- Mike > > On 27 Jan 2012, at 07:29 , David Sewell wrote: > >> We're getting ready to implement the prototype of a new project and will >> need to >> make a semi-final decision about whether to run it as a pure 100% >> MarkLogic-driven web service (setting up a MarkLogic HTTP server on port >> 80), or >> whether to have Apache listen on port 80 and hand things off to MarkLogic as >> necessary. >> >> In the past, we have done the latter, using httpd.conf to set up virtual >> hosting and proxying rules such that *.xqy URLs get handed off to MarkLogic >> while Apache handles *.html?, etc. This was in an environment where we >> needed to >> be able to use certain Apache features such as the PHP modules, server-side >> includes, etc., for legacy PHP/HTML content. >> >> The new environment is being designed from the ground up in MarkLogic, so it >> would seem much more economical and efficient to run only the MarkLogic >> server. >> Of course the ML HTTP server isn't as infinitely configurable as Apache >> (which >> is maybe a good thing, on the whole). This seems like the way to go, but from >> other folks' experience are there any considerations that would lead you not >> to >> rely on MarkLogic for HTTP service in a single-server environment? >> >> David >> >> -- >> David Sewell, Editorial and Technical Manager >> ROTUNDA, The University of Virginia Press >> PO Box 400314, Charlottesville, VA 22904-4314 USA >> Email: [email protected] Tel: +1 434 924 9973 >> Web: http://rotunda.upress.virginia.edu/ >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
