I definitely also agree with the previous two responses, I do the same and run BioMart as documented using it's own back-end specificly compiled apache+mod_perl with a separate already existing front-end apache doing reverse proxy.
-L On Tue, Nov 30, 2010 at 12:37 PM, Dr James A Smith <j...@sanger.ac.uk> wrote: > On 30/11/2010 11:15, Bob MacCallum wrote: > >> I would run it in a separate back-end apache and use mod_proxy and >> ProxyPass directives in your existing front-end apache (some >> recompilation may be necessary - configure options "--enable-proxy" >> "--enable-proxy-ajp" - the latter is for a tomcat backend) >> >> I agree with Bob here, unless your biomart is very small I would say that > you can do it - but DON'T you will find that the performance of your > webserver will drop considerably! Also Mart can be very easily DoSed by > legitimate users of the web interface (or more increasingly the services > interface) > > This is the experince the Ensembl team had. They actually run mart under > its own dedicated webservers (and they struggle with the huge demands for > memory of a large biomart) - but the server serving mart ONLY serves mart > dynamic content (it doesn't even serve mart static content) which is handled > by the main ensembl servers. The team had to limit the number of children on > the BioMart instances to no more than 15-20 children due to extreme memory > requirements of the BioMart system for a large mart, otherwise the instances > would run out of memory (and these are 16/32 G machines) - they still do if > users generate weird queries - the servers both backend databases servers > and frontend MySQL servers are regularly DOSed by legitimate users using the > web interface. We have also recently noticed other DOS attacks on > martservice URLs where in efficiently written queries are generating large > numbers of small queries for whom the backend MySQL backs up - and so delays > responses to the martservice request - e.g. requests which look for genes > overlapping a region from within a given list - each return on average 10 > bytes of data - but each request actually takes somewhere between 15 seconds > and 2 minutes to return because of constraints on the MySQL tables.... > > James >
