Tips & Tricks on Data caching

Results 1 to 6 of 6

Thread: Tips & Tricks on Data caching

  1. #1
    Join Date
    Dec 1969
    Posts
    228

    Default Tips & Tricks on Data caching

    Hi guys.<BR><BR>First, I don&#039;t have any real problems, I&#039;m only seeking advices & tricks from more experienced people than myself.<BR><BR>I just got the green light to implement data caching in our application.<BR><BR>We&#039;ll be caching our "Employee" table since it is the most accessed table of the whole application.<BR><BR>What I intend to do is use XML & the ADO Stream object. When the app. start I&#039;ll read all employees and store it as XML in an APPLICATION variable.<BR><BR>Each page needing to read an employee will copy that xml locally and create a recordset with it.<BR><BR>When an employee is modified, a function called say "RefreshEmployees" will be called to update both DB and XML.<BR><BR>I&#039;ve got pretty much everything figured out but I just thought I&#039;d come here and ask if any of you ever did something like this and if you are aware of obstacle I might encounter or problems/performances issues I should be on the lookout for.<BR><BR>Questions / Suggestions?<BR><BR>Thanks a lot.<BR><BR>Stephane Dorion

  2. #2
    Join Date
    Dec 1969
    Posts
    1,686

    Default Never used it

    but sounds useful. Keep us posted on your progress.

  3. #3
    Join Date
    Dec 1969
    Posts
    16,931

    Default Are your...

    ...web and database servers different physical machines? If they aren&#039;t, you&#039;re probably going to actually get a decrease in speed, rather then an increase.<BR><BR>Here&#039;s my reasoning (I may have missed something, btw!):<BR>1) You load information (XML) into an application variable on application start (or whenever).<BR>2) Each page copies this XML to a local variable and creates a new RecordSet object from it. It then filters that recordset object and uses it accordingly.<BR><BR>How much processor/memory usage is the second step going to take? Have you done any kind of stress testing? I&#039;d be surprised if the increase is great, especially if you&#039;re using a decent DB. How are your tables? Optimised etc?<BR><BR>As Bronx said - keep us posted on your progress. I&#039;m very interested how it goes. Can you give us some information on your kind of setup (web/db servers, number of hits, size of the table you&#039;re looking at, that kinda thing)?<BR><BR>Craig.

  4. #4
    Join Date
    Dec 1969
    Posts
    228

    Default Our structure

    Indeed, you got it right for the reasoning.<BR><BR>But..that&#039;s what we want :)<BR><BR>Here&#039;s why.<BR><BR>Our database sucks, it is not optimized....darn...it&#039;s not even in 3rd normal form (I&#039;m not sure that how we say it in english).<BR><BR>Due, to the structure, we have to access the same "Employee" table 3 times (minimum) per page. Even though we can&#039;t see it because we haven&#039;t released the application yet, I know its going to cause a lot of stress when 100+ people starts browsing the website. (All in all, a typical page will call the DB 8-10 times!!! per page...trust me, my skills have nothing to do with :-) )<BR><BR>We already use .filter pretty everywhere and I&#039;m more inclined stressing the web server than the DB since the web server is dedicated, not the DB.<BR><BR>Besides, should the ado.filter prove to be too stressful, we can always use filter the XML using XSL then create the recordset on the filtered XML.<BR><BR>I&#039;ll definitely keep you posted guys.


  5. #5
    Join Date
    Dec 1969
    Posts
    3,195

    Default My question is how often is this data

    changed? <BR><BR>Also do any other applications change this data? Is it frequently? If yes, you might want to periodically refresh your data?<BR><BR>Now on a different note, employee data is usually very sensitive information and depending on the company there can be very complex and expensive human resource systems used to administer it ; )<BR><BR>I just want to make sure that you take the necessary precautions in your application to protect it and make sure only the people who should see specific info actually see only that ; )<BR><BR>Good luck<BR>Pete

  6. #6
    Join Date
    Dec 1969
    Posts
    228

    Default Not too often

    Employee records shouldn&#039;t be changed that often. But I intend to refresh the XML as soon as an employee is changed.<BR><BR>I&#039;ll have a function like this :<BR><BR>UpdateEmployee(ArrayOfFields, ArrayOfValues)<BR><BR>Function UpdateEmployee(ByRef prmarrFields, ByRef prmarrValues)<BR>On Error Resume Next<BR><BR>...<BR>&#039;Get Employees via XML string<BR>&#039;Transform to recordset<BR>&#039;.AddNew<BR>&#039;.Update (send changes to DB)<BR>&#039;App.Lock, copy RS back in XML (Refresh) and App.Unlock<BR>...<BR><BR>UpdateEmployee = Err.Number<BR>End Function<BR><BR>I understand your concerns about security, I have the same, I worked for the HR department for a long time and I am well aware just how cautious we gotta be. Trust every precaution is taken to avoid someone seeing what he should not.<BR><BR>With this innovation, I can improve security even more later by using XSL.<BR><BR>Thank you for your input<BR><BR>Stephane Dorion<BR><BR>err..hum...Godspeed :)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •