Central Forums Helpbot
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Pages: [1]   Go Down
Print
Topic: Potential performance tweak for Vhabot  (Read 1275 times)
« on: May 28, 2011, 07:41:53 PM »
Apprentice coder
VhaBot Developers
Novice

View Profile
***

Epeen: 4
Posts: 446


Whilst troubleshooting an issue with Firefox today .. I came across a new query command for SQLite, the database backend library that Vhabot uses for all its storage/lookup functions. In order to clean up the databases Firefox uses, they recommend the use of a 'VACUUM' function which removes empty space left by deleted data, and re-creates the database with clean indexes, etc.

I have just tried this on a few key databases Vhabot uses [the users.db3, notify.db3 and vhrostermanager.db3 are typical large and important key database files for an orgbot] and noticed a significant shrink in filesize.

I'm not going to make wild and over-stated claims of performance improvement, but for orgs where there is a turnover of players, or particular difficulties with delayed responses in-game, you may wish to try this method:

Open your database file in an appropriate client [ SQLiteSpy is a good Windows client, or sqlite3 on *nix hosts works fine ] and simply execute vacuum;<enter>. You may notice a slight delay whilst it does its stuff. Save/Flush/Exit as appropriate, et voila.

The main cause for in-game lag of responses with Vhabot and moderate size orgs with many Alts, is down to issues with the "People of Rubi-Ka" or 'PoRK' website, which does take somewhat of a pounding from bots. Being a Funcom site, there isn't a whole lot we can do about this, and many will be aware of its habit of throttling or completely dying .. but Vhabot does have a method for caching /whois requests [which are frequently called for various functions] and falling back to another Character data website.
Llie has posted here a note about her findings, and a few suggestions are being discussed about what, if any, adjustments can be made to accommodate this limitation.
Additional pressure on Funcom to give some attention to the updating of 'PoRK' and increased reliability is desirable, but we appreciate that it is a low-priority concern with other game developments taking place.

Any feedback on the database tweak is, as always, welcomed.
« Last Edit: April 09, 2013, 09:41:08 PM by veremit »
Logged
Pages: [1]   Go Up
Print
Jump to: