Server
From Mugshot Developer Wiki
| Server | |
| | |
| Design Process | |
| Current Phase: | Implement |
|---|---|
| People | |
| Engineers: | Colin Walters, Havoc Pennington, Marina Zhurakhinskaya, Owen Taylor |
| Ethnographers: | Nobody |
| Designers: | Bryan Clark, Mike Langlie |
| Multi-Disciplinary: | Donald Fischer |
| | |
| Blog: | |
| Bugzilla: | |
| SVN: | |
Contents |
About the Server
When we say Server, we mean the set of code that runs in a central location. The server provides the web interface for users directly, and also communicates with the Linux Client and Windows Client behind the scenes. Together the server and the clients build the use experience described in Web Swarm and Music Radar.
The server uses pretty standard technology: the majority of the custom Mugshot server code is a Java application running in the JBoss application server. Database access is done using the Hibernate implementation of EJB Persistance. We're currently using MySQL as the database backend, though we've done some testing with PostgreSQL as well. We also have extended the Jive Wildfire XMPP server to handle communication with the client.
Source Code
See the Server Code Overview for a detailed description of how it all fits together, and the Server Development Setup for information about how to get set up to work on the server.
Server Activity Ideas
For more general user-focused ideas, see Activity Ideas; what is listed here is just a few projects that involve changing the internals of the server while leaving the user experience the same. If you are interested in one of these activities, you should create a new activity page for it and link to that here.
Improve caching
The Mugshot web pages display lots of information pulled from different parts of our data model; without any caching, a single page might require dozens of separate database queries. Right now, we use the Hibernate second-level cache to reduce the number of queries we are making and also use custom caching in some situations, but there's a lot more that could be done.
Split the workload across computers
This is obviously a huge area. Right now the server code just runs on a single computer. It would be easy to divide up the existing processes between different computers: run the Apache web caching on one computer, the database on another, JBoss on another, Wildfire on another. But the benefits of doing this are pretty small: at best you can scale up to 4-5 times as many users. To really make progress, you need to be able to split the work of handling XMPP traffic and web traffic across many computers. Some of this could be done using standard techniques, such as HTTP load balancing and a distributed cache like the JBoss cache. But distributing the work of maintaining live state like who's in a chat room at the current time would likely require more custom approaches.
Move the chat room code into JBoss
Right now there is a lot of complexity involved in communicating back and forth between the Wildfire XMPP server and the code running in the JBoss application server about the status of chatrooms ... who is in them, what was said, and so forth. If we ran the chatrooms inside the JBoss process, a lot of things would get simpler. There are a lot of different ways of doing this: we could run wildfire itself inside JBoss, we could make the chatrooms a Jive external component, or we could write our own XMPP server, possibly using the same "whack" library as Wildfire.
Running your own Mugshot server
You can run your own instance of the Mugshot server, but presently this is mostly useful for testing and debugging work; i.e. on features you plan to send to the mugshot.org server. We haven't done any work on a federation system, so separate Mugshot instances would be islands. Mugshot at the moment is the most useful if everyone uses the same server.
But nothing stops you from running your own or reusing the code! For more information see Server Development Setup.
