On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
We are investigating using IPC rather then a file based
structure but its purely investigation at this point.
What are the speed diffs between an IPC cache and a
Berkely DB cache. My gut instinct always screams 'Stay Off
The Disk' but my gut is
On 21 Aug 2002 at 2:09, Ask Bjoern Hansen wrote:
Now using good old Fcntl to control access to simple flat files.
(Data serialized with pack(N*, ...); I don't think anything beats
pack and unpack for serializing data).
The expiration went into the data and purging the cache was a simple
Hi Peter --
The morale of the story: Flat files rock! ;-)
If I'm using Apache::DBI so I have a persistent connection to MySQL,
would it not be faster to simply use a table in MySQL?
Unlikely. Even with cached database connections you are probably not going
to beat the performance of
Jesse Erlbaum [EMAIL PROTECTED] wrote:
Hi Peter --
The morale of the story: Flat files rock! ;-)
If I'm using Apache::DBI so I have a persistent connection to MySQL,
would it not be faster to simply use a table in MySQL?
Unlikely. Even with cached database connections you are probably
Hey James --
One way to think about it is this: MySQL stores its data in
files. There
are many layers of code between DBI and those files, each of which add
processing time. Going directly to files is far less code, and
less code is
most often faster code.
MySQL also stores indices.
Ask Bjoern Hansen wrote:
The performance? I don't remember the exact figure, but it was at
least several times faster than the BerkeleyDB system. And *much*
simpler.
In my benchmarks, recent versions of BerkeleyDB, used with the
BerkeleyDB module and allowed to manage their own locking,
Peter J. Schoenster wrote:
If I'm using Apache::DBI so I have a persistent connection to MySQL,
would it not be faster to simply use a table in MySQL?
Probably not, if the MySQL server is on a separate machine. If it's on
the same machine, it would be close. Remember, MySQL has more work
--- Perrin Harkins [EMAIL PROTECTED] wrote:
There are a few ways to deal with this. The
simplest is to use the
sticky load-balancing feature that many
load-balancers have. Failing
that, you can store to a network file system like
NFS or CIFS, or use a
database. (There are also
On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote:
I can definitely get it all from the db, but that doesn't
seem very efficient.
Don't worry about whether it *seems* efficient. Do it right, and then
worry about how to speed that up - if, and only if, it's too slow.
Premature optimisation is
We do see some slowdown on our langauge translation db
calls since they are so intensive. Moving to a 'per child'
cache for each string as it came out of the db sped page
loads up from 4.5 seconds to .6-1.0 seconds per page which
is significant.
Currently we are working on a 'per machine'
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want
We are investigating using IPC rather then a file based
structure but its purely investigation at this point.
What are the speed diffs between an IPC cache and a
Berkely DB cache. My gut instinct always screams 'Stay Off
The Disk' but my gut is not always right.. Ok, rarely
right.. ;)
John-
md wrote:
I haven't looked at the cache modules docs yet...would
it be possible to build cache on the separate
load-balanced machines as we go along...as we do with
template caching?
Of course. However, if a user is sent to a random machine each time you
won't be able to cache anything
Thanks...you've given me plenty to work with. Great
explination. This is good pragmatic stuff to know!
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
[EMAIL PROTECTED] wrote:
We are investigating using IPC rather then a file based structure but
its purely investigation at this point.
What are the speed diffs between an IPC cache and a Berkely DB cache. My
gut instinct always screams 'Stay Off The Disk' but my gut is not always
Thanks, you just saved us a ton of time.
Off to change course ;)
J
On Tue, 20 Aug 2002 13:12:29 -0400
Perrin Harkins [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
We are investigating using IPC rather then a file based
structure but
its purely investigation at this point.
What are the
understand the theory to work anyway.
Josh
[EMAIL PROTECTED]
08/20/2002 10:54 AM
To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED]
cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:Re: Apache::Session - What goes in session?
We do see
::Session - What goes
in session?
We do see some slowdown on our langauge translation db
calls since they are so intensive. Moving to a 'per
child'
cache for each string as it came out of the db sped page
loads up from 4.5 seconds to .6-1.0 seconds per page
which
is significant.
Currently we
Not in the MS house that I am living in right now :^(
On Tue, 20 Aug 2002, Perrin Harkins wrote:
Ian Struble wrote:
And just to throw one more wrench into the works. You could load up only
the most popular data at startup and let the rest of the data get loaded
on a cache miss.
I'm using mod_perl and Apache::Session on an app that
is similar to MyYahoo. I found a few bits of info from
a previous thread, but I'm curious as to what type of
information should go in the session and what should
come from the database.
Currently I'm putting very little in the session, but
Hello md --
I'm using mod_perl and Apache::Session on an app that
is similar to MyYahoo. I found a few bits of info from
a previous thread, but I'm curious as to what type of
information should go in the session and what should
come from the database.
One thing to watch out for is the trap
md wrote:
Currently I'm putting very little in the session
Good. You should put in as little as possible.
what I am putting in the session is more global in
nature...greeting, current page number, current page
name...
That doesn't sound very global to me. What happens when users open
Thanks though. That was succinctly put.
Could you go back in time and tell me that a year or two ago?
That would be great, thanks again.
-Josh
:)
Things like the login status of this session,
and the user ID that is associated with it go
in the session. Status of a particular page
has
--- Perrin Harkins [EMAIL PROTECTED] wrote:
md wrote:
That doesn't sound very global to me. What happens
when users open
multiple browser windows on your site? Doesn't it
screw up the current
page data?
I don't think global was the term I should have
used. What I mean is data that
md wrote:
I don't think global was the term I should have
used. What I mean is data that will be seen on all or
most pages by the same user...like Hello Jim
Okay, don't put that in the session. It belongs in a cache. The
session is for transient state information, that you don't want to
--- Perrin Harkins [EMAIL PROTECTED] wrote:
Current page name and id are never stored in db, so
different browser windows can be on different
pages...
I thought your session was all stored in MySQL. Why
are you putting
these in the session exactly? If these things are
not relevant
md wrote:
We are using a load-balanced
system; I shoudl have mentioned that earlier. Won't
that be an issue with caching to disk? Is it possible
to cache to the db?
There are a few ways to deal with this. The simplest is to use the
sticky load-balancing feature that many load-balancers have.
27 matches
Mail list logo
