#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
22450
12546
3910
>sigh!< My back made public... 
