Actually that will probably do.
If i merge the content log and cache log based on time and content then i
should be able to work out what people have seen.
regards Pete
-----Original Message-----
From: Avi Kivity [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 16, 2000 1:18 PM
To: [EMAIL PROTECTED]
Subject: Re: An Eloquent and Sophisticated Caching system Design ?
>
> Hi Avi
>
> >this design allows you to separate the cache from the content
> >generator, thus improving scalability.
>
> That is the problem, I need to have caching (perhaps with a
> proxy server as
> you suggested) and logging. The logging is the most important
> thing here. So
> what I want is the best of both worlds. Cache will give me
> performance like
> a static web site, logging will give me the merits of a
> generated web site.
>
>
> For example when the first request comes in for a web page I
> need to do four
> steps:-
>
> 1. generate the content for the page request
> 2. log which content has been show on that page
> 3. cache the page
> 4. return the web page to the user
>
> then when the second request comes in it will use the cached
> page so I do
> this:-
>
> 1. find the cached page for the page request
> 2. log which content that has been show on that page
> 3. return the cached web page to the user.
>
> I do not see how a proxy server can accomplish step number 2.
> Normal logging
> done by a web server (e.g. Logging which page is served by
> the proxy server
> or indeed the parameters of the request for the page) is
> insufficient as
> this information will not directly reflex which content I
> actually show on
> the cached page. For example the cached page my contain
> content that has
> randomly been selected (perhaps an add banner) and so I need
> to make a log
> of this.
You can merge the content generator log with the cache log.
For example, to find out what content was shown for
http://some.url.com/request?parameters, you would scan the content log from
the time of the hit backwards. The first match of the URL would give you the
content.
Alternatively, if you use get-if-modified, you can log the requests at the
content generator.
>
> Problem is more complex than it first seem. If it I did not require
> extensive logging then using a proxy server would be ideal.
>
Using a dedicated proxy seems best. Why implement a cache, which has to deal
with synchronization issues, staleness, amount of storage, when others have
already done so? Just augment the logging, using the way I outlined above or
any other way.
> Any more solutions, peeps ?
>
>
> -----Original Message-----
> From: Avi Kivity [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 16, 2000 12:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: An Eloquent and Sophisticated Caching system Design ?
>
>
> This is what a proxy server (i.e. squid) does, so I see no problem.
> In fact, this design allows you to separate the cache from the content
> generator, thus improving scalability.
>
> - Avi
> --
> s/\be(\w+)/e-\1/g;
>
> > -----Original Message-----
> > From: Peter Delahunty
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 16, 2000 11:20
> > To: [EMAIL PROTECTED]
> > Subject: An Eloquent and Sophisticated Caching system Design ?
> >
> >
> > To the Guru's
> >
> > Has anyone ever built a caching system using servlets ?
> >
> > This is my scenario, I have a web site running on EJB and
> > servlets which are
> > used to produce dynamic web pages. However these web pages do
> > not change
> > very often and so if I could cache the HTML that is generated
> > it would speed
> > up the web site loads. This mean I wouldn't have to keep
> > going to the ejb
> > layer each time.
> >
> > Now here is the catch.
> >
> > I need to log the information our users are seeing. So for
> > example if a web
> > page is generated that shows product 1,2 and 3. I need to log this
> > information. This is simple if the servlet EJB layer is used.
> > However if I
> > have a cached page this layer is never called. However I
> > still need to log
> > the information. I have done an few prototypes using a front
> > end servlet to
> > do the caching. However servlets are not designed for chaining.
> >
> > What I mean by that is it is hard for "servlet A" to call
> > "Servlet B" and
> > read the output of that servlet into say a string. With
> > servlets you can
> > only "nest" them using requestdispatcher.
> >
> > One design I have is to intercept a call to the servlets
> > running my site.
> > Then to open a URL connection to that servlets read in the
> > response (eg
> > HTML) to a string store that string in a cache (perhaps a
> > hashtable) then
> > return the response to the user. Then the next time the same
> > request comes
> > in I will get the HTML string from the cache. I have logging
> > built into this
> > by calling a shared log object that is stored in the servlet
> > context when
> > the HTML is first generated by the EJB/servlet layer.
> >
> > SO then what I want to know is has anyone else done
> anything like this
> > before and do they a better solution. I think the current
> > design is messy
> > and want a more eloquent solution
> >
> > Regards Peter
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
