It’s funny how one of the key things I needed to remove to make my site usable is one of the first things someone else recommends adding to make Drupal sites usable - and we’re both right.
RealJenius.com for all intents and purposes is a low-traffic site. It’s certainly more than most of the sites I host for small businesses or for my family, but all-in-all, the traffic and load is low.
I suffered at my last host for many reasons, as is well documented here, but one such reason was the communication time between the database and my web server was just too high. My current configuration of RealJenius.com favors several queries, and even with caching enabled, it needs a fairly efficient transfer from the DB to the web server.
When I moved to a MediaTemple DV, my SQL server and Web server became one in the same, and now communication between MySQL and PHP is lightning-fast. Granted, this is compounded by the fact that my server is much less overwhelmed than the piece-of-garbage I was on at nightmarehost.
John & Cailin have a very good article on the steps to scale a Drupal install to higher and higher demand - and their first recommendation is to move the database off of the web server. Of course, this configuration makes sense, because if they are sharing the same hardware, they are sharing several resources, including memory, CPU cycles, and IO cycles.
The most scalable configurations, however, will also carry with them some fixed costs. There is a natural overhead in technologies like clustering, load balancing, and networked decoupling; in many ways similar to the constraints applied by Amdahl’s Law. You can’t just double the servers, and expect double the performance.
Of course, the same differences can be applied to programming - the fastest algorithms for reasonably small sets may be very resource-hungry, using gobs and gobs of memory; the fastest data structure sorting and searching can be done when the whole data tree is in memory for example. However, if that structure gets large enough, you can quickly run out of resources, exposing the fact that the algorithm is not very scalable.
It’s up to the developer to decide the trade-offs at this point - how much data is a reasonable amount, and how much scalability do you really need.
You often pay a cost for scalability, and I was paying the cost for my host’s need for scalability, and they weren’t doing anything to relieve the performance headaches their ‘scalable’ architecture was creating for their users.
1 Responses (Leave a Comment):
That was a good way to illustrate the distinction.
My pet peeve is the confusion (among professional writers who should know better) about the meaning of the word "robust." Robust does NOT mean "feature-rich"; it means "strong, durable, reliable." A robust program is one that won't crash; not one that gives the user lots of options.
Australopithicaus Robustus was given that name NOT because he could do more things than the other austrolopithicenes, but because he had thicker bones (that were, presumably, harder to break). A robust wristwatch is one that a diver can take down 300m without leaking -- not a chronography with four different dials that breaks if it shake it too vigorously.
Unfortunately, we have a bunch of technical writers in this field who have little respect for the English language, and like Lewis Carrol's Humpty Dumpty, think they can make a word mean whatever they want it to mean.
Post a Comment