Performance

Image Serving

Firstly, make sure your webserver is configured properly and nice URLs are enabled, so that images will be served straight from disk by the webserver instead of via PHP. If you're serving images via PHP, then your site might melt under the load of 5 concurrent users...

Server

While any web server should work, nginx has been found to work particularly well

Running PHP in FastCGI mode (eg via PHP-FPM) should reduce startup overhead a lot.

Software Cache

Install a key / value store like memcached or redis, and then add to shimmie.conf.php: define("CACHE_DSN", "memcache://127.0.0.1:11211"). A bunch of stuff will then get served from the high-speed cache instead of the SQL database.

HTTP Cache

Varnish makes everything better. The default behavior of "anons see cached pages that are up to two minutes old, logged in users get fresh data" is pretty close to perfect, though you may want to increase the TTL for some pages (image lists / search results may change often, individual images not so much)

Note that this behaviour works correctly because shimmie only sets a session cookie when a user is logged in, no cookie for anonymous users; the front-end settings cookies are prefixed with ui- and are then removed by a regex in the config file. If you modify shimmie to add new cookies (or you have ads on your site, which have their own cookies), you'll also need to modify the Varnish config to ignore them too.

Example varnish config file

Software tweaks

Setting SPEED_HAX to true in shimmie.conf.php will make a bunch of changes which reduce the correctness of the software and increase admin workload for the sake of speed. You almost certainly don't want to set this, but if you do (eg you're trying to run a site with 10,000 concurrent users on a single server), it can be a huge help.

Notable behaviour changes:

• Database schema upgrades are no longer automatic; you'll need to run php index.php db-upgrade from the CLI each time you update the code.
• Mapping from Events to Extensions is cached - you'll need to delete data/cache/shm_event_listeners.php after each code change, and after enabling or disabling any extensions.
• Tag lists (eg alphabetic, popularity, map) are cached and you'll need to delete them manually when you feel like it
• Anonymous users can only search for 3 tags at once
• We only show the first 500 pages of results for any query, except for the most simple (no tags, or one positive tag)
• We only ever show the first 5,000 results for complex queries
• Only comments from the past 24 hours show up in /comment/list
• Web crawlers are blocked from creating too many nonsense searches
• The first 10 pages in the index get extra caching
• RSS is limited to 10 pages
• HTML for thumbnails is cached

CDN support

If serving images and thumbs from a set of mirrors, one can load balance by setting eg: the image url to http://mirror-{a=25,b=25,c=50}.mysite.com/_images/$hash/$id - $tags.$ext. Shimmie will then spread the load over those three servers, using a consistent hash for distribution (consistent meaning that if you add or remove a server from the list, as many URLs as possible will stay the same)

Data Store

Settings WH_SPLITS to 2 in shimmie.conf.php will store files as images/ab/cd/... instead of images/ab/..., which can reduce filesystem load when you have millions of images.

Profiling

If you want to help make the software itself as fast as possible, a good starting place is to see what's slow right now: define()'ing TRACE_FILE to a filename and TRACE_THRESHOLD to a number of seconds will result in JSON event traces being dumped into that file whenever a page takes longer than the threshold to load. These traces can then be loaded into the chrome trace viewer (chrome://tracing/) and you'll get a breakdown of page performance by extension, event, database, and cache queries.