ASP classic - speed difference between FSO and #include
I've built a CMS which works quite nicely - one of the ways it works is by processing templates, with custom tags in it - pretty common across many CMS's. My question is really a bit open ended - basically, how fast is it to read several small text files using the FSO, under high traffic? Is this likely to bottleneck?
For instance, any given page might load (server-side, using FSO) a header, a footer, an ad-block, a navigation menu, a content block, etc. - all from text files stored on the server. This works nice and quickly, but I'm worried the disk-reads will slow the site down under high traffic.
Also, I'm processing dynamic custom tags, that don't just load a file, but produce something from a database, such as a table of figures. Part of the plan with the tags/text-files, etc. was to be able to cache the database bits to disk, as some of them don't change very often, and in previous projects, reading from the DB has been the bottleneck. However, is the overhead of reading text from a disk higher than reading it from a DB? If it is, there's probably not much point me caching the DB stuff. I'm using SQL 2003 with IIS7 and ASP classic.
Any comments appreciated!
For instance, any given page might load (server-side, using FSO) a header, a footer, an ad-block, a navigation menu, a content block, etc. - all from text files stored on the server. This works nice and quickly, but I'm worried the disk-reads will slow the site down under high traffic.
Also, I'm processing dynamic custom tags, that don't just load a file, but produce something from a database, such as a table of figures. Part of the plan with the tags/text-files, etc. was to be able to cache the database bits to disk, as some of them don't change very often, and in previous projects, reading from the DB has been the bottleneck. However, is the overhead of reading text from a disk higher than reading it from a DB? If it is, there's probably not much point me caching the DB stuff. I'm using SQL 2003 with IIS7 and ASP classic.
Any comments appreciated!
"basically, how fast is it to read several small text files using the FSO, under high traffic? Is this likely to bottleneck?"
Yes, if you have high traffic, do not use FSO in this fashion. You will likely experience excessive resource consumption, as well as timeouts from file locking.
Yes, if you have high traffic, do not use FSO in this fashion. You will likely experience excessive resource consumption, as well as timeouts from file locking.
ASKER
Thanks for the comments above. Any idea what physical limits might be? Also, I appear to have two contradicting comments - one saying files will be cached by OS, and another saying I'll suffer file-locking - any idea actually what might happen? How do popular CMS systems like Joomla, Wordpress, etc do it? I thought many of them worked in a similar fashion...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks guys - in some ways, not the answer(s) I was hoping for, but it makes sense. I'll have to load test to see what sort of split I can safely work with - I'll file cache db heavy stuff, and pull the lighter bits on the fly.
SQL Server database should be far faster than reading files on disk drive. I will stick to the DB engine rather to the hard drive.
Think that users will use the browser cache for files like images, etc, to they won't be solicited to the server reducing stress and consider coockies to store some information rather than saving it to the database or disk.
Hope that helps,
Pancho