Asylum Feedback/Support

Audio Asylum feedback, support and feature wish list.

Use this form to submit comments directly to the Asylum moderators for this forum. We're particularly interested in truly outstanding posts that might be added to our FAQs.
You may also use this form to provide feedback or to call attention to messages that may be in violation of our content rules.

You must login to use this feature.

Inmate Login

By default, logging in will set a session cookie that disappears when you close your browser. Clicking on the 'Remember my Moniker & Password' below will cause a permanent 'Login Cookie' to be set.

Moniker/Username: The Name that you picked or by default, your email. Forgot Moniker?	Examples "Rapper", "Bob W", "joe@aol.com".
Password:	Forgot Password?
	Remember my Moniker & Password ( What's this?)

If you don't have an Asylum Account, you can create one by clicking Here.

Our privacy policy can be reviewed by clicking Here.

Inmate Comments

From:
Your Email:
Subject:

Message Comments

Original Message

Re: connection refused, and also having to click twice on links

Posted by Rod M on November 7, 2003 at 07:25:13:
It's a combination of factors. The first is traffic. We've had a major increase over the last month or so. Average traffic has increased from around 600K page views per day to consistently over 800K pages with 18,000 unique users and 9GB of data transferred per day. The increased load has taxed both the servers and the connection.
Secondly, I've been doing quite a number of changes to improve the efficiency. The db was upgraded and optimized, loads have been balanced somewhat between servers and some new summary tables were created. Unfortunately, building some of these improvements puts an additional load on the servers and has affected performance while the jobs were running resulting in periodic connection problems.
The db has also grown a lot as we have nearly 2 million messages, so we're due for an upgrade to a much faster server which will surely help, but is also expensive. In the meantime, the new summary tables are smaller and should result in better performance.
eThreads is a good example. It was quite slow. Now, it uses a much smaller summary table that is somewhat dedicated, so you should see an improvement. The Classic view is cached as html, so it does tend to be faster. eThreads is completely data driven, so performance varies on the speed of the db server and size of the tables.
In any case, all of the changes are now in place, so the additional load of creating and loading new tables is over. We'll be monitoring performance to ensure that we've improved it and it should be better. However, if the connection problems relate to bandwidth issues, then we have another expensive problem that would require a colo server or additional T1 to address.