Tag Archives: MIIS

Gratitude At Work: Lessons from Berkeley

Creating a culture of appreciation was the culminating session at a recent UC Berkeley ‘Greater Good Science Center‘ event on gratitude and well-being at work.

logo - Gratitude and Well-being at Work conference

Click image to explore the conference website

An exploration of both the ‘how’ and the ‘why’ of gratitude practices, the sessions took an increasingly practical focus as the day progressed:

  • What is gratitude, and why practice it at work? (theoretical frameworks & research) 
  • How to get started:  Debunking myths, overcoming barriers (existing programs, in context) 
  • Putting gratitude into practice (small-scale, practical activities) 
  • Building cultures of gratitude and appreciation (momentum & long-term organizational change) 

Participation in this event was made possible by the Monterey Mindfulness at MIIS Working Group, and we will be sharing the experience through a face-to-face campus event in Monterey and via the Mindfulness at Middlebury site.

Got questions?  Want to dive in?

Contact sarah.springer@middlebury.edu to receive a one-time update when resources for learning about and putting these ideas into practice are available.

Are you reading this post via a feed reader? If so, read on…

On Tuesday May 31st we’re going to change the categories on this blog, so if by any chance you’re using a feed of a specific category, that’s going to break. We suggest subscribing to the whole blog for maximum enjoyment! If you’re not a LIS staff member & would like to filter out the more staff related posts, you can subscribe to the new “Middlebury Community Interest” category after May 31st. The other categories will be “LIS Staff Interest”, and “Post for MiddPoints” which will cause the post to be added to the MiddPoints blog too. All the old categories except “The Essentials” will be converted to tags for easy searching.
The LIS Web team developed this new scheme, following recommendations that came out of the open meeting about the future of the LIS Blog (including a call for simplified categories). The AD Team reviewed and approved these changes. We welcome your comments.


The Monterey Institute of International Studies is hosting a Tedx event.  TED refers to the wildly successful annual conferences that bring together people from technology, entertainment and design to give short talks about their lives.  Tedx events are community organized programs that following a similar format to the TED conferences.

TedxMonterey is happening on April 15 and will be livestreamed and live-interpreted to the web.   Speakers will include dancers (including Middelbury’s Andrea Olsen), drummers, environmentalists, researchers, entrepreneurs and artists.

MiddLab Discussion Sessions Follow-up

Thank you to everyone who was able to attend either of my discussion meetings for MiddLab last week! There were a lot of great ideas for the site and upcoming projects. You can now see one of those ideas added to the site in the new Research Centers page which shows a map of all the MiddLab projects. We’re going to continue adding features to the site throughout the semester, so stay tuned.

While we were not able to record the sessions due to some technical difficulties, I have prepared a guide to adding your project to MiddLab. Feel free to edit that page to add your own tips on creating a successful project description or send an email to middlab@middlebury.edu if anything is unclear. I will host another meeting to discuss MiddLab during the Spring semester, for those who were not able to attend, but I’m also more than happy to meet individually with Faculty, Staff, Students, departments, and offices.

Publications Database

During a discussion with Bob Cluss and Colleen Converse, we came up with an idea for a sub-site in MiddLab that serves as a portal to discover publicly available academic publications from our faculty and students. I’ll be working on adding that this semester and welcome you to send documents or (preferably) links to these papers in public databases to middlab@middlebury.edu. If the document is larger than 10MB, please send it to website@middlebury.edu instead. If you already have a site that lists these documents that you’d like to be included, you can also just send that link and I’ll take care of the rest.

Look for this information to be added to MiddLab shortly, giving people both on and off-campus another easy way to find information on the active and ongoing research at Middlebury.

Working More Closely with You

I also want to make you aware of a small change in policy about the inclusion of content in MiddLab. Due to some concerns about the unfortunate rules surrounding some academic publication and to ensure that all research collaborators are willing to be included, we’ll now ask that every person involved in a research project agrees to have it hosted in MiddLab before it is put up. I can also remove content from the site where your name appears if you would not like it published in this manner. You can see any mention of your work in MiddLab by browsing the People page. Please address any concerns to middlab@middlebury.edu.

Website Performance: Pressflow, Varnish, Oh-My!

Executive summary:

We’ve migrated from core Drupal-6 to Pressflow, a back-port of Drupal-7 performance features. Using Pressflow allows us to cache anonymous web-requests (about 77% of our traffic) for 5-minutes and return them right from memory. While this vastly improves the amount of traffic we can handle as well as the speed of anonymous page-loads it does mean that anonymous users may not see new versions of content for at most 5 minutes. Traffic for logged-in users will always continue to flow directly through to Drupal/Pressflow and will always be up-to-the-instant-fresh.

Read on for more details about what has change and where we are at with regard to website performance.


When we first launched the new Drupal website back in February we went through some growing pains that necessitated code fixes (Round 1 and Round 2) as well as the addition of an extra web-server host and database changes (Round 2).

These improvements brought our site up to acceptable performance levels, but I was concerned that we might run into performance problems if the college ended up in the news and thousands of people suddenly went to view our site.

At DrupalCon a few weeks ago I attended a Drupal Performance Workshop where I learned a number of techniques that can be used to scale Drupal sites to be able to handle internet-scale traffic — not Facebook or Google-level traffic, but that of The Grammys, Economist, or World Bank.

Since before the launch of the new site we were already making use of optcode-caching via APC to speed code execution and were doing data caching with Memcache to reduce the load on the database. This system-architecture is far more performant than a baseline setup, but we still could only handle a sustained average of 20 requests each second before the web-host started becoming fully loaded. While this double our normal average of 10-requests per second, it is not nearly enough headroom to feel safe from traffic spikes.

Diagram of the execution flow through the web-host using normal Drupal page caching.

Request flow through our Drupal web-host prior to May 13th; using normal Drupal page-caching stored in Memcache. Click for full-size.

Switching to Pressflow

Last week we switched from the standard Drupal-6.16 to Pressflow-6.16.77, a version of Drupal 6 that has had a number of the performance-related improvements from Drupal-7 back-ported to it. Code changes in Pressflow such as dropping legacy PHP4 support and using only MySQL enable Pressflow execute about 27% faster than Drupal, a useful improvement but not enough to make a huge difference were we to get double or triple our normal traffic.

For us, the most important difference between Pressflow and Drupal-6 is that sessions are ‘lazily’ created. This means that rather than creating a new ’session’ on the server to hold user-specific information on the first page each user sees on the website, Pressflow instead only creates the session when the user hits a page (such as the login page) that actually has user-specific data to store. This change makes it very easy to differentiate between anonymous requests (no session cookies) and authenticated requests (that have session cookies) and enables the next change, Varnish page caching.

Varnish Page Caching

Varnish is a reverse-proxy server that runs on our web hosts and can return pages and images from its own in-memory cache so that they don’t have to execute in Drupal/Pressflow every single time. The default rule in Varnish is that if there are any cookies in the request, then the request is for a particular user and should be transparently passed through to the back-end (Drupal/Pressflow). If there are no cookies in the request, then Varnish assumes correctly that it is an anonymous request and tries to respond from its cache without bothering the back-end.

Request flow through our Drupal/Pressflow web-host after May 13th; using the Varnish proxy-server for caching. Click for full-size.

Request flow through our Drupal/Pressflow web-host after May 13th; using the Varnish proxy-server for caching. Click for full-size.

Since about 77% of our traffic is non-authenticated traffic, Varnish only sends about 30% of the total requests through to Apache/PHP/Drupal: all authenticated requests and anonymous requests where the cache hasn’t been refreshed in the past 5 minutes. Were we to have a large spike in anonymous traffic, virtually all of this increase would be served directly from Varnish’s cache, preventing any load-increase on Apache/PHP/Drupal or the back-end MySQL database. In my tests against our home-page varnish was able to easily handle more than 10,000 requests each second with the limiting factor being network speed rather than Varnish.

A histogram of requests to the website. Y-axis is the number of requests, X-axis is the time to return requests, '|' requests were handled by Varnish's cache and '#' were passed through to Drupal. The majority of our requests are being handled quickly by Varnish while a smaller portion are being passed-through to Drupal.

A histogram of requests to the website. Y-axis is the number of requests, X-axis is the time to return requests, '|' requests were handled by Varnish's cache and '#' were passed through to Drupal. The majority of our requests are being handled quickly by Varnish while a smaller portion are being passed-through to Drupal.

MySQL Improvements

During the scheduled downtime this past Sunday, Mark updated our MySQL server and installed the InnoBase InnoDB Plugin, a high-performance storage engine for MySQL that can provide twice the performance of the built-in InnoDB engine in MySQL for the types of queries done by Drupal.

Last week Mark and I also went through our database configuration and verified that the important parameters were tuned correctly.

As the MySQL database is not currently the bottleneck that limits our site performance these improvements will likely have a minor (though wide-spread) effect. Were our authenticated traffic to further increase (due to more people editing for instance) these improvements will be more important.

Where We Are Now

At this point the website should be able to handle at least 20,000 requests/second of anonymous users (10,000 on each of two web-hosts) at the same time that it is handling up to 40 requests/second from authenticated users (20 on each of two web-hosts).

While it is impossible to accurately translate these request rates into the number of users we can support visiting the site, a very rough estimation would be to divide the number of requests/second by 10 (a guess at the average number of requests needed for each page view) to get a number of page-views that can be handled each second. (1)

In addition to how many requests can be handled, how fast the requests are returned is also important. Our current response times for un-cached pages usually falls between 0.5 seconds and 2 seconds. If pages take much longer than 2 seconds, the site can “feel slow”. For anonymous pages cached in Varnish response times range from 0.001 seconds to 0.07 seconds, much faster than Apache/Drupal can do and more than fast enough for anything we need.

The last performance metric that we are concerned with is about the time it takes for the page to be usable by the viewer. Even if they receive all of the files for a page in only 0.02 seconds, it may still take their browser several seconds to parse these files, execute javascript code, and turn them into a displayable graphic. Due to these factors, my testing has shown that most pages on our site take between 1 and 3 seconds for users to feel that our pages are loaded. For authenticated users, this stretches to 2-4 seconds.

Finally please be aware that, anonymous users see pages that may be cached for up to 5 minutes. While this is fine for the vast majority of our content, there are a few cases where we may need to have the content shown be up-to-the-second fresh. We will address these few special cases over the coming months.

Future Performance Directions

Now that we have our caching system in place our system architecture is relatively complete for our current performance needs. While we may do a bit of tuning on various server parameters, our focus now shifts to PHP and Javascript code optimization to further improve server-side and client-side performance respectively.

One big impact on javascript performance (and hence perceived load-time) is that we currently have to include two separate versions of the jQuery Javascript Library due to different parts of the site relying on different versions. Phasing out the older version will reduce almost by half the amount of code that the browser has to parse.

Additional Notes

(1) As people browse the site their browser needs to load the main HTML page as well as make separate requests for Javascript files, style-sheet (CSS) files, and every image. After these have been loaded the first time, [most] browsers will cache these files locally and only request them again after 5 minutes or if the user clears their browser cache. CSS files and images that haven’t been seen before will need to be loaded as new pages are browsed to. For example, the first time someone loads the Athletics page, it requires about 40 requests to the server for a variety of files. A subsequent click on the Arts page would require an additional 13 requests, while a click back to the Athletics page would require on 1 additional request as the images would still be cached in the browser.



MiddLab is a new section of Middlebury’s website with no precedent: an academic network, uniting all of the… blah, blah blah.

Truth is, MiddLab has been hard for us to explain ever since we heard the idea. A research network featuring discussions and blogs, and linking together disciplinary themes? How does that work? Rather than write a manifesto, here is what we’re trying to accomplish with MiddLab.

Our Goals

  • Make research easy to discover. If you want to know what student and faculty research is going on in a department, you shouldn’t have to know where their papers are published or the address of the project’s web site. Instead, these should be one or two clicks from our home page.
  • Show connections between research. Whether researching the population growth of trees in Biology or the population density of people in Geography, projects share themes and people interested in the topic can easily explore both.
  • Start a discussion. We encourage and recommend that you add comments to the projects on this site. Ask questions, suggest new research, or explain why you disagree with the conclusions. You can add your thoughts to any project page on MiddLab, explore the individual blogs for some projects, or contact the researchers directly.
  • Provide space for research and the sciences on our site. We’ll be expanding this site to feature more presentations from the Spring Research Symposium and research projects in our science departments. Though MiddLab is open to any student, faculty or staff projects, these are areas where we know we’re not offering enough information on our site and would like to use MiddLab to expand.

Your Feedback

We aren’t sure these are the right goals for our site. We’d like to hear from people: what would you like to see in MiddLab? What parts of this site work toward these goals and which don’t? Leave your thoughts by commenting on this page.

Oh, and if you would like us to feature your project in MiddLab, send an email to middlab@middlebury.edu.

Monterey Terrorism Research and Education Program

One of the Internet resources featured in the latest issue of the Internet Scout Report, at http://scout.wisc.edu/Reports/ScoutReport/2010/scout-100402.html, is the Monterey Terrorism Research & Education Program, at http://www.miis.edu/academics/researchcenters/terrorism.  Based at the Monterey Institute of International Studies, the Monterey Terrorism Research & Education Program (MonTREP) “conducts in-depth research, assesses policy options, and engages in public education on issues relating to terrorism and international security.”  Their team of scholars looks at violence-prone extremist groups and their historical evolution, organization structure, and operational methods. Most people will want to look at their Islam, Islamism, and Politics in Eurasia Reports (IIPER).  The IIPER is a bimonthly compendium of news and analysis on politics involving Islam in the former Soviet Union.  The reports are written and edited by Dr. Gordon M. Hahn, and the series also accepts independent submissions as well. Visitors are welcome to browse through the reports here, and they may end up forwarding them to friends and associates. Finally, the site also includes a “News & Student Stories” area which reports on the activities of current members of the team, alumni, and students.