|
ASP, CGI and PHP Scripts and Record-Locking: What Every
Webmaster Needs To Know
|
By Sunil Tanna
[Hits: 16713]
|
|
Many of us install server-side (ASP, CGI or PHP) scripts on ourweb sites, and many of this scripts store data on the server.However, poorly designed scripts can experience performanceproblems and sometimes even data corruption on busy (and not sobusy) web sites.
If you're not a programmer, why should this matter to you?
Answer: Even if you're just installing and using server-sidescripts, you'll want to make sure that the scripts that youchoose don't randomly break or corrupt your data.
First, some examples of the types of scripts which store data onweb servers include:
(Of course, many scripts in each of these (and other) categoriesare well-designed, and run perfectly well even on very busy websites).
1. Follow-up autoresponders typically store the list ofsubscribers to the autoresponder, as well where in the sequenceof messages, each subscriber is. Examples of autoresponderscripts: http://www.scriptcavern.com/scr_email_auto.php
2. Classified ad scripts store (at least) a list of all theclassified ads placed by visitors. Examples of this type ofscript: http://www.scriptcavern.com/scr_classified.php
3. Free for all links scripts store a list of all links postedby visitors. See some example scripts listed at:http://www.scriptcavern.com/scr_ffa.php
4. Top site scripts usually store a list of the members of thetop site as well as information about the number of "votes" thateach has received. For examples of this type of script, seehttp://www.scriptcavern.com/scr_topsite.php
So what kind of scripts have problems? And what sort of problemsam I talking about?
Well the principle problems all relate to what happens when bitsof data from multiple users needs to be stored on updated at thesame time. Some scripts handle these situations well, but othersdon't...
DATA CORRUPTION
Here's a common data corruption problem that can occur with manyscripts:
1. When some bit of data needs to be updated, a copy of theserver-side script starts running, and then starts updating it.
2. If another user comes along and does an update before thefirst copy of the script has finished, a second copy of thescript starts running at the same time.
3. There are a number of ways things can now go wrong, forexample:
(a) What if the first copy of the script reads in the data, thenthe second copy reads the same data, then the first copy updatesthe data, then the second copy updates the data? Answer: anychanges made by the first copy of the script can get lost.
(b) What if the first and second copy of scripts are both addingmultiple bits of new data to the store at the same time? Forexample, imagine each needs to store the headline, descriptionand the name of the person posting a classified ad. Well, whatcan happen (with some scripts) is the two classified ads can getintermingled, so you might get (for example) HEADLINE-1,DESCRIPTION-1, HEADLINE-2, PERSON-1, DESCRIPTION-2, PERSON-2. Orworse yet, you might get bits of each part of each classifiedad, mixed with the bits of the other. This type of thing isusually really bad news, as your data may consequently becomingunusable from that point on.
Does this sound too unlikely a problem to worry about? Don'tbank on it... even if it happens only 1 time in 1,000, or 1 in10,000, eventually it will happen: You need a solution.
So the real question is: is it possible for programmers tocreate scripts without these kinds of problems? Fortunately theanswer is yes, and there are a number of ways that programmerscan address it:
1. They can store each bit of data in a separate file. Thisisn't necessarily a total solution by itself (in particular, ascript which just does this could still have problems ifmultiple copies of a script update the same file at the sametime), but it does make data corruption less likely, and ifcorruption does occur, at least it won't corrupt the entire datastore in one go.
2. They can use file-locking. This means that if one copy of ascript is working with a file, another copy of the script isprevented from working on that file, until the first copy hasfinished. File-locking works if done correctly, but programmingit into a script needs to be done very carefully and precisely,for every single possible case... even a tiny bug or omissioncan allow the possibility of data-corruption in through thebackdoor!
3. They can use a database (such as MySQL) to store the data.Provided the data is properly structured in the database, thedatabase handles the locking automatically. And, as theprogrammer doesn't have to write their own special lockingroutines, the possibility of bugs and omissions are much reduced.
PERFORMANCE PROBLEMS
Of course, avoiding having your data corrupted should be theparamount consideration in choosing a script, but is thereanything else we need to be concerned about?
Answer: Performance
Of course, all webmasters are aiming to build busy high trafficweb sites... but will your scripts be able to handle the load?
Go back and re-read the paragraph on file-locking. Now thinkabout what would happen if all the classified ads on yourclassified page were stored in a single file (or all the linkson your top site, or all the subscribers to your autoresponder,etc.).
What would happen?
Answer: Because each update can only be performed after theprevious update has been completely finished, your site may beslow, or even unable to handle all your users' requests.
So what's the solution?
There's two options that programmers can use:
1. They can use lots of small files and file-lock eachindividually (for example, one per classified, one per top sitelisting, etc.). Of course, this needs to be handled verycarefully...
2. They can use a database (like MySQL), as databases allow anyone individual record ("row") to be updated, even when anotheris also being updated.
IN CONCLUSION
Now, let's summarise:
1. Scripts that store data in files need to use file-locking toavoid data-corruption, and they also need to break the data intoseparately updateable chunks to avoid performance problems onbusy web sites.
2. Scripts that store data in databases (like MySQL), providedof course that they have been properly coded, are usually lesslikely to suffer from data-corruption or performance problems.
And one additional point:
3. Even the best script is not immune to hard-disk hardwarefailures, your web host being struck by lightning, and all theother snafus that can happen. So, do take regular back-ups ofany data that you can't afford to lose!
In short, even if you're not a script programmer, you need to beaware of data storage issues. In future, when considering ascript for your web site, don't be afraid to ask some hardquestions about how it stores data and how well it handlesmultiple users.
This article is Copyright (C) 2005, Answers 2000 Limited.
About the Author: This article was written by Sunil Tanna ofAnswers 2000. For a directory of ASP, CGI, PHP and Remotelyhosted scripts, please visit http://www.scriptcavern.com - andfor scripts written by Answers 2000 please visithttp://www.scriptrocket.com-----------------------------------------------------------------
-----------------------------------------------------------------
Publication Terms And Conditions:
Answers 2000 Limited grants you a free non-exclusive permission(license) to publish a copy of this article on your web site oropt-in ezine, subject to you complying with ALL of the following:
1. You must publish the article in full and unedited (exceptthat you may omit this Terms and Conditions section, you mayomit the word count, and you may correct any typos that youmight find). 2. If you publish on a web site: (i) you must makeALL links clickable, (ii) you may format the article to fitwithin your web site's design, (iii) you must include thecopyright notice and "About the Author" section at the end. 3.If you publish in an ezine: (i) your ezine must be opt-in withyour users having specifically elected to subscribe to yourezine and with the ability to unsubscribe at any time, (ii) youmust include all link URLs unedited and in full, (iii) you mayformat the article to your ezine's layout, (iv) you must includethe copyright notice and "About the Author" section at the end.4. To the maximum extent permissible under law, this article isprovided "AS IS" without warranties of any kind whether expressor implied. 5. These terms and conditions shall be governed byand construed in accordance with the laws of England and Wales.Any disputes arising from matters relating to this article shallbe exclusively subject to the jurisdiction of the courts ofEngland and Wales. You agree that any legal action againstAnswers 2000 Limited (or its directors, officers, or employees)relating to this article or this agreement will be brought inthe courts of London, England, however Answers 2000 Limitedreserves right to pursue breach of these terms in anyjurisdiction.
There are 1225 words in this article (including title and Aboutthe Author section).
-----------------------------------------------------------------
|
|
|
|
|
|
