I was wondering, I am doing my best to eliminate a lot of Database queries that are unneeded in order to increase performance. However, this is a tough task as each solution has its own drawback which I then have to compare to see which ones would be better performers, under which circumstances.

Without getting this too complex, I will let you know what I am asking.

I was wondering which would be more costly in terms of CPU usage, resources taken, etc. All in efforts to increase the amount of requests the server can take at a time, and to decrease the amount of time it takes to process each request.

Currently I am logging each view into a database. This means that if I have 20,000 views in that day over so many different files, that's 20,000 queries to the database to change the amount of "views". This I am reconstructing.

What I am planning on doing is putting the views in an xml file along with all information regarding that file. Along with this, views need to be updated in the database as well, lets say every 2 - 4 hours, depending on the time and load of the server at the time.

I will be logging each view on each category on each file. This means that I have roughly 82,000 files that are being viewed. I need to log the amount of views that each file takes within a 2-4 hour period. Every 2-4 hours, the file is put into an archive, and a new one is created with a value of zero.

So here are the options, and please let me know what you think of each:

1. I can update the xml file, along with a txt file that just includes the amount of views. At the interval times, the txt file can be read, and the value can be inserted into the corresponding record in the database. The bonus of this option is that the xml file will be read and bound to the page. After this has happened, a request will be made with certain information to a page that will update the xml file and the txt file behind the scenes. This means only one file is used to read from for each user.

2. I can have the database tapped for views, which will update the views at the same time. This means less server load, but is are pointless database taps.

3. I can store all views in a certain xml file, read through, retrieve the value, display it, update the file with the new views. The problem I see with this one is that every user then uses two files for some information. However, I can quickly upload the entire file to the database for quick updating. (This might be better as it will take less time on the database server than the others).

Thank you for any help. You can offer other suggestions as well. I gotta run, so I am cutting this short. Thanks again!

In case any of you are wondering, I will be updating only the files that have been accessed within that time period. This will be done by another file, most likely txt, but possibly xml. This file will contain the name and location of the file. Then, when the time comes to upload, it will read through the file, line by line, and substitute in the filename and location to further commands, which will update the according file to the database.

I think I will just update the xml file and the txt file. Then when the time comes, I will read the information from the text file (which are just views), and add them to the database. An example of this would be:

txt file:
117 UPDATE tblname SET views=views+@views WHERE rowid=@id Any suggestions are still welcome! Thank you.

What are you logging in the database, is it just page views?
If so just turn on IIS logging and download IIS Log Parser http://www.logparser.com

You can query the log parser and make it update a log table. Just have a scheduled task run the update once a day.

I'll look into it. Currently the server is on a host where I cannot manage any settings on the SQL server, so I am not sure if that will work.

In about 4 months I will be moving it to a highly secured and private server, where I have control, completely, and just pay for the bandwidth and equipment rental.

But until then, I'll have to improvise. But I will keep this in my future enhancements file :)

Thank you.

This article has been dead for over six months. Start a new discussion instead.