mysql

This december, it will have been 5 years since I created the first user for this site. Since then, there's always been a notion of a webteam. Though the webteam has from time to time been contributing to parts of the contents of the site, I don't think I am being unfair to any of the current and past webteam members if I say that I have been the sole contributor to the actual working of the site.

As I mentioned in my previous post, the site was bottlenecked by having the Apache/PHP and MySQL servers on two separate machines. This is the standard setup at Dreamhost; even if you have a PS, the mysql part is hosted on a different server. So even if you don't have to share a machine with other websites hosted on Dreamhost, you're still sharing their network latency when the Apache/PHP server is communicating with the MySQL server. On a typical non-cached page, the IVRPA site makes 200-400 queries to the database.

Since the migration, the site has been having performance issues. While I had hoped that the site perfromed better with a newer version of Drupal, we're actually seeing worse performance.

At long last, I have implemented an automated system for handling payments from users of the sites becoming a member and/or renewing their membership. Before this, for years, our treasurer was handling each payment manually. This caused (mostly minor) delays, and some confusion among our paying 'customers' (that means you, members!) when payments did not have that 'instant gratification' of getting member privileges.

On januari 19, our then-current webhost Bluehost suspended our website due to 'excessive MySQL use'. All our sites, as well as the mailing lists (so in short, all our means of communicating with our membership) were shut down; a hard to miss 'notice' that we had outgrown the services Bluehost was willing to extend us at our shared hosting.

We've been having some issues with our hosting. Some of you might have been seeing red error messages instead of content from time to time. This is due to issues at our host, CIHost.

We're on a shared server. Whenever someone else on our server uploads one or more very large files, the /tmp partition fills up. This means that other file uploads will fail, but far more importantly, MySQL will fail doing even the simplest of SELECT statements with an 'error 28'. Unfortunately, this seems to happen quite often. Looking through the logs of the site, I have traced back 4 incidents:

Neo

Is that...

Cypher

The Website? Yeah.

Neo

Do you always look at it encoded?

Cypher

Well you have to. The MySQL databse works for Drupal. But there's way too much information to decode the website. You get used to it. I...I don't even see the code. All I see is blonde, brunette, red-head.

I'm having some fun converting the Drupal user database to and from the IVRPA member database. The IVRPA member database is kept up to date in Filemaker Pro. It's a rather simple affair; a single table with lots of columns (values) and rows (members). The Drupal user database on the other hand is a bit more complex and relational.