Challenge this!!!

goh_gss

Anyone got idea how to keep the perfomances if acess a database every second by thounsand people to get a live report.

MarkR

Well if it's the same report you could just cache it in a server-side file, and serve it from there if it exists.

But take care to lock where necessary otherwise you could get race conditions causing bad things to happen (like serving a partially generated cache file)

Mark

goh_gss

The report might update every second , so when user view it must access from database??cahce is for the same report?

bubblenut

Replication?
Have one server which handles all writes and then multiple slaves which are read only and update from the master continuously. They will have a small lag but if they're geographically close to each other, there are not a huge number of inserts/updates going on and the slaves are not subjected to huge long queries the lag should be very small indeed.

blahpro

This is a disk space killer - but try perhaps having 50 database tables with the same structure that are updated in turn, and query them each in a cycle (i.e. 1 then 2 then 3 ... then 50, then 1...)?

goh_gss

then query a cycle for 50 tables will take some time?

blahpro

No, I mean on the 1st second, query table one. On the second second, query table two - up until the 50th second, where you query table 50. Then, on second 51, you query table 1 again.

See what I am trying to say?

goh_gss

how about update? if update have to update all the table also?
else the information will not complete

blahpro

Well, it also updates the tables in turn - i.e. table 2 while you are querying table 1, tabel 3 while you are querying table 2 etc

AstroTeg

You can identify the lag you have will be with the hard drive's I/O.

An alternative is to put the data in RAM. The procedure to do this is to keep the database on the hard disk and replicate that data to RAM. Although in your case, you might have the RAM version replicate to the hard disk. You'd do this at an interval of your desire. Using transactions would be a great idea too since during each replication of say 10 minutes, you'll have 10 minutes of fresh data you could lose in a power failure. So if you save the transactions to disk, you can rebuild and update the hard disk version from the last point your RAM one died.

Although this is all in theory. I believe you'll need an industrial database engine to make this work reliably.

blahpro

Puts my suggestion to shame.

weeps