 |
 |
Older 3.x versions of Blacklight may have put a solrmarc.jar inside your app's ./config/SolrMarc. That may not be caught by your slug ignore. This was an error, it was never meant to do that. If you have one in a BL 3.x you should be safe to remove it. Other than that, I'm curious what's making a BL app so large! Incidentally, you don't need a ./jetty in your local app _at all_, unless you actually want to keep a jetty Solr there. BL will optionally install one there, but it's not required. (Does slug size include your gem dependencies? I am not familiar with heroku. Cause the BL gem itself _does_ also include a SolrMarc.jar, if that's a problem, we'd have to refactor things on the BL side to make it an optional dependency instead of baked into BL). On 3/29/2012 12:37 PM, Chris Fitzpatrick wrote: > Hey Sean, > > Jah, I did that...my .slugignore is: > tmp/* > log/* > coverage/* > spec/* > koha/* > jetty/* > > That dropped it down to 30 from ~50mb, so that's good . > (koha has some scripts wrote to pull from our ILS). > > I think the slug size is a really minor issue. Heroku says under 25mb > is good, but over 50mb is not so good. Not "Good", but not "Chaotic > Evil" . "Neutral Good". > > > > On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannan<[log in to unmask]> wrote: >> If you already have everything indexed in Solr elsewhere, a way to cut down >> the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable. >> >> -Sean >> >> >> On 3/29/12 12:16 PM, "Chris Fitzpatrick"<[log in to unmask]> wrote: >> >>> Hi, >>> >>> I've deployed Blacklight on both Heroku and Elastic BeanStalk. >>> >>> Heroku is still a much better choice. The only issue I had was I >>> needed to make sure the sass-rails gem in installed in the :production >>> gem group and not just development. >>> >>> I still have an issue of getting heroku to compile all my >>> sass/coffeescript/etc assets on update, but it actually doesn't seem >>> to make much of an impact on performance. The minor issue is that it >>> would be nice to figure out a way to slim down BL's slug size. The >>> lowest I've been able to get it is about 30mb and Heroku recommends >>> having it be below 25mb. >>> >>> I have not used Heroku's solr service (I still use EC2 for my solr >>> deployments). >>> EngineYard would also be another option. >>> >>> There is also an AMI for DSpace, so deploying that to EC2 should be >>> pretty easy.... >>> >>> b,chris. >>> >>> >>> >>> On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz<[log in to unmask]> wrote: >>>> Erik, >>>> >>>> I haven't tried it (recently) on PaaS providers, but I have on IaaS. The >>>> AMIs I've created in association with start up scripts (if you're >>>> interested in seeing those let me know, I'd have to look for them somewhere >>>> or other) mean that the application automagically starts up on its own, all >>>> you need to do is go to the URL. I've used this as a back up method in the >>>> past and I think would be a great way for people to be able to play with >>>> the different apps before committing. >>>> >>>> To this end, I created an AMI for Blacklight a while back: >>>> http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out >>>> of date. I also have instructions on creating an EBS backed AMI: >>>> http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which >>>> is the method I used for creating the Blacklight AMI. These instructions >>>> are also fairly old, but I still get comments on my blog now and then that >>>> the method works. >>>> >>>> I also played around with it on Heroku, but that was so long ago I don't >>>> think any of the things I learned still apply (this was when Heroku was >>>> fairly new to the scene). Hope some of this helps. >>>> >>>> Rosalyn >>>> >>>> >>>> >>>> On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland<[log in to unmask]>wrote: >>>> >>>>> Dear Erik, >>>>> >>>>> Bram Wiercx and myself have given a talk on how to put together a package >>>>> to install CollectiveAccess on Red Hat's OpenShift: >>>>> http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce >>>>> s-as-a-service-solution >>>>> . >>>>> >>>>> My students are currently happily playing around with CollectiveAccess, >>>>> which they have installed on OpenShift. My teaching assistant Max De Wilde >>>>> has developed clear guidelines on how to run the installation procedure: >>>>> http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. >>>>> >>>>> It would be wonderful to aggregate these kind of installation procedure's >>>>> for other types of LIS applications... >>>>> >>>>> Kind regards and looking forward to your book! >>>>> >>>>> Seth van Hooland >>>>> Président du Master en Sciences et Technologies de l'Information et de la >>>>> Communication (MaSTIC) >>>>> Université Libre de Bruxelles >>>>> Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles >>>>> http://homepages.ulb.ac.be/~svhoolan/ >>>>> http://twitter.com/#!/sethvanhooland >>>>> http://mastic.ulb.ac.be >>>>> 0032 2 650 4765 >>>>> Office: DC11.113 >>>>> >>>>> Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have been toying with the process of implementing common LIS >>>>>> applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers >>>>>> like Heroku and Amazon Elastic Beanstalk. I have just tried out of >>>>>> the box distributions so far and have not made much progress but was >>>>>> wondering if someone else had tried this or had ideas about what >>>>>> issues I might run into. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Erik >>>>>> >>>>>> Erik Mitchell >>>>>> Assistant Professor >>>>>> College of Information Studies >>>>>> University of Maryland, College Park >>>>>> http://ischool.umd.edu