Remember: Join our IRC channel if you need more help.
How to Install
Place the Prism.jar file in your bukkit
/plugins directory. Start your server and an initial configuration file will be created.
At the very least, you must setup a database connection - read below if you need help with MySQL, or sqlite (no-install database).
Make sure you have MySQL installed. Most of you likely do already, but some of you are new to MySQL. If you really don't want to install anything, you can use sqlite - but please read about the differences below.
We really recommend you use MySQL, but if you're unable to or would rather not install it, we also offer sqlite support (please read the FYI section below for the differences).
Make sure the
database.mode config says "mysql". Every MySQL connection needs to have an address, a username, a password, and a database.
Enter your database
hostname (the address to the mysql server, usually the default is
localhost. Enter the username/password for the server, defaults to
root and an empty password.
*If you setup your MySQL server yourself, you should know what the above information is. If you're using a mysql server setup by someone else (like on a shared hosting service), they will provide you the information. *
Make sure you have an empty database available - either use an existing database or create a new one. The name isn't important, as long as you enter the database name into the config.
Start your server and look for any console errors saying that Prism can't connect to a database.
Note sqlite support is not currently available in Prism 2
Sometimes it's just easier to not use MySQL. MySQL has to be installed and run as a server. Maybe you're not comfortable trying (see tutorial videos we link to!) or maybe you can't. Sqlite is an alternative, and you don't need to install any software - bukkit handles it for you.
However, Prism will be a lot faster and more efficient with MySQL. See the full explanation below.
If you still want to use sqlite, set
FYI: MySQL vs sqlite
MySQL is software that you can install on your computer (works on Windows, Mac, and Linux) that creates a database service - a very fast, efficient place for Prism (and many other plugins) to store data.
We HIGHLY recommend using MySQL (especially if your server is very active) because it's faster, more efficient both in disk use and in locking, and is more stable than sqlite.
Prism offers sqlite support primarily for smaller, low traffic servers and players with no experience or willingness to work with MySQL. sqlite has multiple limitations that means the Prism experience will be slower than when using MySQL.
sqlite is a basic database system that generally doesn't require installation. Plugins can create a database in their own directory and there's no installation/setup required of you.
We do not recommend using sqlite unless your server offers fewer than 20 player slots. sqlite is much slower when used with default java libraries (currently three times slower than mysql in Prism tests) and is less efficient with storing data (file size increases much faster than MySQL).
If you're concerned about disk space or if you have a busy server, we recommend leaving off
water-flow and turning off
lava-flow tracking. These events not only occur with extreme frequency, but Bukkit also fires these events multiple times per block location. They can very quickly saturate your database. It's relatively easy to use
/prism drain instead.
However, Prism tracks lava/water-break events even if flow is disabled, so you can still rollback the items broken by the liquid.
We get technical here. If you're not sure what these recommendations refer to, please skip.
Constantly seeing pool exhaustion errors? The cause normally isn't prism, but a problem communicating with the database fast enough. There's a lot you can do.
If you have a remote mysql server, it's usually a lot slower because the server has to communicate across the internet every query, and shared mysql hosts are usually a bit lax on performance.
Recommendation: Decrease the pool wait times. Increase the pool connection limit if your remote mysql provider has a limit that will fit it. If you can spare a little more memory, increase the actions per batch so a mysql query sends more data during larger changes.
Advanced Database Configurations
We allow you to make some adjustments to how we connect and talk to a database - which is useful if you either have a remotely-hosted mysql server or want to increase performance because you have a local mysql server you control.
prism.database.max-pool-connections defines how many connections we can use as a max. If your database provider only allows a lower number, then adjust this to match. It's not common that you'd need to increase this but that depends on the volume of data being logged. Even for higher capacity servers the default should be ok.
prism.database.max-wait defines how long the pool will wait for a connection. This generally shouldn't need to be adjusted.
Faster Event Logging
Our defaults for the speed of event logging are set to sensible defaults with the medium-range servers average owners use. However, if you have more control over your server you can tweak Prism to record events faster.
actions-per-insert-batch refers to how many actions are sent per batch insert. The only things that limit this are memory (ram), and your mysql server's setting for
max_allowed_packets. It's very possible to increase this number to
5000 or higher.
Every time the recorder runs, it will empty the queue with batch insert statements, and by changing it to 5000 instead of 1000, increases the speed that the queue is emptied dramatically. A 110k block world edit saves in 19 seconds with the default settings, but saves in 5 seconds with the increased batch size.
queue-empty-tick-delay - This determines how many ticks (20 ticks = 1 second) the recorder will wait before checking the queue again. Setting this to a lower number will increase the speed of queue saves. For example, the default is 3 ticks which roughly means 6 queue empty actions per second.
When the recorder checks the queue, it will empty the entire queue in batches, so either way the queue will be emptied, this setting simply makes it check for newer actions more often.