Forum Moderators: open
Would this be a good optimization or will I be actually slowing things down with file reads?
Any feedback appreciated, thanks.
I would suggest that you try loading pieces of that page using an Ajax implementation. If you aren't familiar with it do some research. I think you will find that more and more sites are using Ajax for faster page loads.... even though it may take the same amount of time for your "widgets" to grab the data and display it to the users... What it will do is present the user with a page... which then loads the smaller widgets after the page has loaded... using little loading graphics in the unloaded widgets will let the user know that there is more data to come but they are now at least looking at your site while they wait for database hits to happen.
I would look into this before switching to flat files.
If you need any Ajax help I can point you to some helpful guides... there are a few good ones on this site as well. Depending on your backend scripting language this should be a breeze and there is a lot of pre-written things to get you going.
Post back so we know how you are making out.
On another note do you think the memory footprint/process creation aspect of loading a file would outweigh the advantages of fast access to the database via an already open database connection?
Under ideal circumstances I think once you have opened a connection for a DB hit... if you can continue to use the same connection for all the hits before closing it.... then the DB might be faster. To get it to a place where the files are faster you may have to look at caching them somehow, this might improve performance over a DB.
The best way to find the answer is to set up a duplicate site... move it over to reading files and then do some load texts on both. Once you have hard numbers to crunch you will have the answer.
To be honest I think the improvement if there was one would be negligible unless under high load times. Since I don't know how busy your site is I am not sure if high load times are an issue.
Can't hurt to set up the test though. if you have time I would love to hear what you do and what the results are.
[edited by: Demaestro at 8:47 pm (utc) on June 13, 2007]
Yes I think a few tests may be in order as they are a lot of variable elements in the equation. It's not the busiest site in the world but it is growing. I just don't want it to become an issue down the line.
I've just had an idea right this moment, maybe instead of writing the cron job HTML to a file I could write it to a record in a special DB table instead and just do the most basic of SELECTs on the already open connection. Could work :)
Do a search in your SQL documentation for it.... basically it will run a query once and get the output as a recordSet.... then when the same query is called it grabs the results from the last time it was run rather then rerunning it...... there are ways of dealing with "stale" results and that sort of thing... could be worth a try as well.
The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.
Uses a defined amount of system memory to mimick a disk drive but works SUPERFAST. If you are working in Linux then you simply need to mount it in the most appropriate place and make sure the permissions are correct (then just write and read as you would normally). I think Windows treats them as different Drive letters but it's equally simple.
You are restricted to pre-defined RamDisk sizes with a default Linux installation if I remember correctly, I think you need to build linux with a custom config to change this default. For your use I think you need not worry.
