Flat files and ASP.NET

[Guest]

Hello

I am developing a system for user tracking. In this I am tracking all the
visitors that came to my website. i developed this using a HTTPModule and
storing the data in a SQL Server database. Everything worked fine till my
website gets good traffic.

When website is getting good traffic, this method is slowing down the entire
application. So I am planning to use flat files instead of SQL Server
database. My doubts are

1 - What is a flat file and how can I connect to it from my ASP.NET
application
2 - If multiple users are browsing website at same time, how can I save
data's to file, because that may be in use.
3 - Is XML files are normal flat files ?

Please help me on this issue.

Sincerly
Navaneeth

 

[marss]

Hello

I am developing a system for user tracking. In this I am tracking all the
visitors that came to my website. i developed this using a HTTPModule and
storing the data in a SQL Server database. Everything worked fine till my
website gets good traffic.

When website is getting good traffic, this method is slowing down the entire
application. So I am planning to use flat files instead of SQL Server
database. My doubts are

1 - What is a flat file and how can I connect to it from my ASP.NET
application
2 - If multiple users are browsing website at same time, how can I save
data's to file, because that may be in use.
3 - Is XML files are normal flat files ?

Please help me on this issue.

Sincerly
Navaneeth

I have a doubt whether saving data to a file on the hard drive is
faster then saving data in the database. Not to mention the speed of
processing these data.

Regards,
Mykola
http://marss.co.ua

 

[Mark Rae [MVP]]

So I am planning to use flat files instead of SQL Server database.

??? Surely not...

2 - If multiple users are browsing website at same time, how can I save
data's to file, because that may be in use.

You can't...

3 - Is XML files are normal flat files ?

XML files are text files, specifically designed as a lingua franca of data
transmission between different systems - they should not be used as a
substitute for a database...

You need to look at optimising your database and how you are connecting to
it - that's where the bottleneck is...

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

I suggest you stick with a database. Flat files will almost certainly not
give you additional speed or scalability.
Perhaps you could use some sort of a queue to save up log records and only
write to the database every so often.

 

[Aidy]

Yes, the OP could look into MSMQ, however what levels of traffic are we
talking here? If it isn't extremely heavy I can't understand why SQL would
be causing a bottleneck. I'd look into what is causing the delay before
looking for an alternative solution.

 

[Mark Rae [MVP]]

If it isn't extremely heavy I can't understand why SQL would be causing a
bottleneck.

Could be any number of reasons: poor design, no primary key / index,
inefficient use of ADO.NET, not closing connections etc...

 

[Aidy]

Could be any number of reasons: poor design, no primary key / index,

inefficient use of ADO.NET, not closing connections etc...

That's what I meant, I don't see that it can be SQL Server's fault but
something to do with the design/coding.

BTW, why would not having an index *harm* insert performance?

 

[John Timney \(MVP\)]

A flat file likely won't help you - ultimately your database does nothing
more than write data to a file. XML is not he right approach either.

You need to either change your approach to tracking data, using perhaps a
hidden iframe in you pages that impacts a second web server instead of your
primary - or look to scale out for load by adding web servers to create a
farm.

Ultimately, a fix is a design decision as your problem could be in the
module rather than he fact that your talking to a database, you could try to
spawn your write activities off to asynchronous threads and see if it
reduces your problems or simply load your data into the application object
and every 1000 requests or so write it to the DB.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Mark Rae [MVP]]

BTW, why would not having an index *harm* insert performance?

 

[Niels Ull]

Yes, the OP could look into MSMQ, however what levels of traffic are

we talking here? If it isn't extremely heavy I can't understand why
SQL would be causing a bottleneck. I'd look into what is causing the
delay before looking for an alternative solution.

I definitely concur with analysing before fixing.

However, it is very likely that a suitably buffered flat file writer will
be faster than committing individual log entries to a database.

Each thread could have its own buffered logger which only flushed to a common
synchronized disk file logger when the buffer is full.
If log entries are timestamped, the ordering of log messages are not important.

Of course, this does run the risk of data loss in case of system failure.

If it is undesirable to have even small waits when flushing to the synchronized
logger, the logger could also be buffered with a separate thread to flush
it to disk.

MSMQ does seem like a bit overkill here, unlesss you really need transactional
support, distribution etc.

XML is not a very suitable format for log files, since they require all content
to be wrapped in a single element. It would, however,
be possible to have a log file containing lots of xml fragments.

Good luck!

Niels

 

[Guest]

Hello,

Using Application variables looks like a good solution to me. But what will
be the performance issues where Application variable grows ? And I think I
will loose unsaved data if any server crash happened

 

[John Timney \(MVP\)]

Performance clearly depends on how much data you stick in the app object
before you archive it off. You'll need to load test whatever your doing.

You always run the risk of losing data in any application crash before its
written to disk/database. What you need to work out is how many records are
you prepared to lose and make sure your write events minimise the impact.
So if you can only lose 10 records then dont wait until 100 to write to the
database.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog