Hello All,
In testing the new req.get_session() method for the upcoming 3.2.0
release I've noticed that the performance of FileSession degrades badly
as number of session files rises. Assuming this is related to putting a
large number of files in a single directory, I decided to do some
bench
Wow, good work Jim.
A bit of perspective:
5 active sessions with an average of 15 mins duration per session means
roughly 4,800,000 requests a day or 55 requests per second.
Jim Gallacher wrote:
Hello All,
In testing the new req.get_session() method for the upcoming 3.2.0
release I've
Nick wrote:
Right, I was thinking the same thing... those are pretty extreme
conditions. But very interesting as a benchmark. I assume ext3?
Yes. It would be interesting to see the same thing on ReiserFS or JFS,
but that will have to wait for another day.
dharana wrote:
Wow, good work J
Right, I was thinking the same thing... those are pretty extreme
conditions. But very interesting as a benchmark. I assume ext3?
Nick
dharana wrote:
Wow, good work Jim.
A bit of perspective:
5 active sessions with an average of 15 mins duration per session
means roughly 4,800,000 requ
On Thu, 16 Jun 2005, Jim Gallacher wrote:
Also I think it's worth the time to squeeze as much performance out of
mod_python as is possible.
+1 on that!
Grisha
Hi Jim,
You've done a pretty impressive work here. What surprises me is the
O(n) behaviour on DBM and FS. This seems to mean that indexes (or
indices, if you prefer) ar not used.
For DBM, well, if BDB could not handle indexes, this would be big
news. Are you 100% sure that the Berkeley implementa
Nicolas Lehuen wrote:
Hi Jim,
You've done a pretty impressive work here. What surprises me is the
O(n) behaviour on DBM and FS. This seems to mean that indexes (or
indices, if you prefer) ar not used.
For DBM, well, if BDB could not handle indexes, this would be big
news. Are you 100% sure tha
Nicolas Lehuen wrote:
Hi Jim,
You've done a pretty impressive work here. What surprises me is the
O(n) behaviour on DBM and FS. This seems to mean that indexes (or
indices, if you prefer) ar not used.
ext2/ext3 uses a linked list to access files, hence O(n) when adding a file.
For DBM, well,
Nicolas Lehuen wrote:
2005/6/17, David Fraser <[EMAIL PROTECTED]>:
I don't know how it could be made good performance-wise, but it would be
great to have a generic database session store that you could pass a
Python DB-API connection object to. Of course, that would be difficult
to configure in
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Brain Wave
It just occured to me that the performance problem may be related to opening
and closing the dbm file for every record insertion. Adjusting the test so
that the file is only opened once, I get O(1), and a great speed boost: 0.2
On Fri, 17 Jun 2005, Nicolas Lehuen wrote:
As for the MySQL implementation
I'd stay away from anything vendor-specific in mod_python, because then
the question becomes why not a postresql, why not oracle, etc.
Grisha
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Brain Wave
It just occured to me that the performance problem may be related to
opening and closing the dbm file for every record insertion. Adjusting
the test so that the file is only opened once, I get
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Nicolas Lehuen wrote:
As for the MySQL implementation
I'd stay away from anything vendor-specific in mod_python, because then
the question becomes why not a postresql, why not oracle, etc.
Any objection to just a SqlSession base c
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but keep the
file open between requests. Not sure if this would be robust or just asking
for dbm file corruption though.
I'm pretty sure it won't work, I think you cannot have a dbm ope
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Any objection to just a SqlSession base class?
May be - it depends on how complex it becomes. Any attempts I've to
generalize SQL/DB stuff tend to become a mess since there are no firm
standards in this area, so this just may be something for the
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but
keep the file open between requests. Not sure if this would be robust
or just asking for dbm file corruption though.
I'm pretty sure it won't wo
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Any objection to just a SqlSession base class?
May be - it depends on how complex it becomes. Any attempts I've to
generalize SQL/DB stuff tend to become a mess since there are no firm
standards in this area, s
Gregory (Grisha) Trubetskoy wrote:
I'm a little concerned about staying focused on closing the last bugs so
that we get to a point where a release can be made, since there hasn't
been one in such a long time...
+1 on that
Nick
2005/6/17, David Fraser <[EMAIL PROTECTED]>:
> I don't know how it could be made good performance-wise, but it would be
> great to have a generic database session store that you could pass a
> Python DB-API connection object to. Of course, that would be difficult
> to configure in the same way as t
2005/6/17, Jim Gallacher <[EMAIL PROTECTED]>:
> It really would be helpful if everyone could read minds. Maybe we could
> put a mind-reading feature in 3.3? :) Although that might push 3.3's
> release back to 2020. And could it be made thread safe...
And if it could be made language-neutral, too,
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but
keep the file open between requests. Not sure if this would be robust
or just asking for dbm file corruption though.
I'm pretty sure it won't wor
Sander Striker wrote:
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but
keep the file open between requests. Not sure if this would be robust
or just asking for dbm file corruption though.
I'm
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I don't
know if it's a good idea to use transaction handling by default for
DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included in the standard python
distribution as
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I don't
know if it's a good idea to use transaction handling by default for
DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included in the standard python
d
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I don't
know if it's a good idea to use transaction handling by default for
DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included in the standard python
d
Jim Gallacher wrote:
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I
don't know if it's a good idea to use transaction handling by default
for DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included i
Jim Gallacher wrote:
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I
don't know if it's a good idea to use transaction handling by default
for DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included i
Nick wrote:
Jim Gallacher wrote:
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I
don't know if it's a good idea to use transaction handling by
default for DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this modul
28 matches
Mail list logo
