Site slowness and migration


Page 2 of 2
Goto page Previous  1, 2
 

Post 

#16  tda42 27 Jan 2005 23:52

The dreaded neon skunk butt hairs.
*sigh* I miss them!
 



 
avatar
blank.gif tda42 Gender: Male
...Pink Paws...
...Pink Paws...
Posette enthusiast
Posette enthusiast
Life + 1
Life + 1
Old Timer
Old Timer
 
Joined: November 2003
Location: Tennessee, The Great Polecat State
Posts: 2551
Tomatoes 22450
Lemons 12546
hearts 3910

  • Back to top Page bottom
 

Post 

#17  pangor 28 Jan 2005 03:42

What secret?  I thought every knew that the active ingredient is full strength sulfuric acid titrated with nitric acid.

That will take the hair (skin, meat, and bone) off of anything real fast.

Pangor
 



 
avatar
 pangor 
Guest
 

  • Back to top Page bottom
 

Post 

#18  Tormie 28 Jan 2005 09:14

>sigh!< My back made public...
 




____________
 
avatar
it.png Tormie Gender: Male
Posette enthusiast
Posette enthusiast
Life + 1
Life + 1
Renderosity Ban
Renderosity Ban
 
Joined: March 2003
Posts: 8280
Tomatoes 72512
Lemons 50450
hearts 5031

  • Back to top Page bottom
 

Post 

#19  pangor 28 Jan 2005 19:50

Until the last two of messages that I posted, I have not noticed the slowness problem.  Now, I have also noticed it.  Tormentor, I don't belive the "data intensive" excuse that you hosting service gave you.  That is a common excuse that is used to explain away poor server/database management.

After I first noticed the slowness I watched the performance for a pattern to the problem.  The pattern that I have detected in the slowness is most often is because of one or more of these three reasons:

1. The database is using a hashing algorithm that had been initialized to provide a certain number of buckets.  As long as the key hashing algoritm is well matched to the keys and the number of available buckets is
much greater than then number records in the database, all is well and both record lookups and creation will be performed in [i:48a20afbfc]O(1)[/i:48a20afbfc] time. If either of these two conditions fail to remain true the number of hashing collisions will rise.  A collision is where the key hashing results in two or more records using the same bucket, then a collision resolution algorithm is used.  The collision resolution algorithms that are most often used are the "List Bucket" and the "Next Bucket" algorithm.

The "Next Bucket" algorithm is easy to program if the key hashes to bucket [i:48a20afbfc]B(n)[/i:48a20afbfc] and the bucket is already in use by a different record, then use [i:48a20afbfc]B(n+1)[/i:48a20afbfc].  This works best only if the bucket array is sparse.  Once the bucket array is no longer sparse, then [i:48a20afbfc]B(n+1)[/i:48a20afbfc] may be in use so try [i:48a20afbfc]B(n+2)[/i:48a20afbfc], then [i:48a20afbfc]B(n+3)[/i:48a20afbfc] etc.  With this method once the bucket array is near capacity, record lookup and record creation time will become bounded by [i:48a20afbfc]O(1)[/i:48a20afbfc] and [i:48a20afbfc]O(z)[/i:48a20afbfc] ([i:48a20afbfc]z[/i:48a20afbfc] is the number of buckets available).  Or in other words, in such a case, the processes will degenerate to near the performance of a seqential search on an unorderd list.  If another record key hahes to bucket [i:48a20afbfc]B(n+1)[/i:48a20afbfc], then there will be another collision to be resolved.

With the the "List Bucket" algorithm instead of buckets being record pointers, they are lists of record pointers.  This is a slightly more complex algorithm, that has a more elegant collision resolution algorithm.  In this case when a key hashes to bucket [i:48a20afbfc]B(n)[/i:48a20afbfc] it then retrieves the record pointer from [i:48a20afbfc]B(n)(m)[/i:48a20afbfc].  If there is a collision on [i:48a20afbfc]B(n)(m)[/i:48a20afbfc] then [i:48a20afbfc]B(n)(m+1)[/i:48a20afbfc] and repeat until the correct slot is found in the bucket.  There are quite a few ways to implement this algorithm each with benefits and problems of their own.  But in almost every instance in worst case situations, it can degenerate that same as the "Next Bucket".

2.  The server a key part of the database is stored in RAM to boost performance.  The RAM requirements of the database has outgrown the amount allocated for its use, resulting in thrashing.

3. Other software (not Posetteforever) is putting a greater demand on the server than had been anticipated, the server is thrashing virtual memory.  Posetteforever recieved the blame, only because you noticed the problem and mentioned it to them.  The other customers using that hardware are also being told that they are the reason for the problem.

Which ever is the case, the migration will be their chance to correct [i:48a20afbfc]their[/i:48a20afbfc] errors.  By the way, if they do it correctly, nobody, not even you should even know that there ever was a server migration.  Unless you examine the DNS records.  If the DNS records were correctly written, then the migrations would not be evident that way either.

Pangor
 



 
avatar
 pangor 
Guest
 

  • Back to top Page bottom
 

Post 

#20  Tormie 29 Jan 2005 21:30

Thank you very much for the technical info pangor. I thought at something similar: you have to know that we were on a different hosting company some times ago and they suspended the account to to high server resources requests from the site. I thought that it was due to Posy's brain and then we wnt here on a Godaddy.com server. Actually Posy is quiet (she is using my virtual credit card...   )and she is not the problem. In any case the sitewas down for about a hour this morning (gmt time), I contacted the support service and they replied that they put the database on a different and faster machine. The problems with the hosting companies are the same every time: I've not the control of the machine where the site is installed. To solve this problem I should do what Landman suggested: Buy a fixed ip with a large broadband and a big computer. It shouldn't be done because I'm not rich and because the site is not a commercial crap and earns nothing. I'm very sorry when it is down, but I prefer a site down sometimes than a ton of spam...
 




____________
 
avatar
it.png Tormie Gender: Male
Posette enthusiast
Posette enthusiast
Life + 1
Life + 1
Renderosity Ban
Renderosity Ban
 
Joined: March 2003
Posts: 8280
Tomatoes 72512
Lemons 50450
hearts 5031

  • Back to top Page bottom
 

Post 

#21  pangor 30 Jan 2005 00:39

I agree.

Talking about the email.  Before the email shutdown is over, if you have access to the outgoing email queue (if one exists) for Posetteforever, check to make sure that it is not hold a large backlog of unneeded email.  Otherwise as soon as the email ban is lifted, that backlog will start to be sent and may go over quota again, right away.

Pangor
 



 
avatar
 pangor 
Guest
 

  • Back to top Page bottom
 

Post 

#22  Tormie 30 Jan 2005 01:30

I have only very little access to the server side, basically I saw that the quota limit is 1000 using phpinfo built in the forum. I hope that the 1000 emails quota is daily... I asked for it to the support service...
 




____________
 
avatar
it.png Tormie Gender: Male
Posette enthusiast
Posette enthusiast
Life + 1
Life + 1
Renderosity Ban
Renderosity Ban
 
Joined: March 2003
Posts: 8280
Tomatoes 72512
Lemons 50450
hearts 5031

  • Back to top Page bottom
 

Post 

#23  pangor 30 Jan 2005 09:32

Hi,

Sorry about posting so many copies of this message.  First I tried posting it here and it seemed to have failed.  Then, I tried a private message and it also seemed to have failed.  So, that is when I sent it in the shoutbox.  Now I find out that each failed attempt of sending the message were [i:93d0dcfd0a]not[/i:93d0dcfd0a] failures after all, making me look like a nag.  

Pangor
 



 
avatar
 pangor 
Guest
 

  • Back to top Page bottom
 

Post 

#24  Tormie 30 Jan 2005 10:14

   ! No problem pangor: The site were not sending mails so it showed the error, but the message was put in the forum anyway. Now all is goinf fine till next webmaster mess      
 




____________
 
avatar
it.png Tormie Gender: Male
Posette enthusiast
Posette enthusiast
Life + 1
Life + 1
Renderosity Ban
Renderosity Ban
 
Joined: March 2003
Posts: 8280
Tomatoes 72512
Lemons 50450
hearts 5031

  • Back to top Page bottom
 


HideWas this topic useful?
Link this topic
URL
BBCode
HTML
HideSimilar Topics
Topic Author Forum Replies Last Post
No new posts Site slowness.... Tormie Whip The Admins... 12 01 Jun 2005 20:24 View latest post
Tormie
No new posts Site slowness... Tormie Whip The Admins... 5 10 Nov 2004 15:14 View latest post
Tormie
No new posts Main page slowness... Tormie Whip The Admins... 7 09 Jul 2008 03:38 View latest post
Tormie
No new posts About pf at another site. TdaC Shebeen, the Staff forum 5 07 Mar 2007 20:27 View latest post
Tormie
No new posts My own site A_C_C Interesting links 5 04 Oct 2006 20:44 View latest post
Guest

Page 2 of 2
Goto page Previous  1, 2



Users browsing this topic: 0 Registered, 0 Hidden and 0 Visitors
Registered Users: None