You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Philip M. Gollucci" <pg...@p6m7g8.com> on 2005/11/29 16:49:27 UTC
B-LexInfo
Hi,
Currently we have
package Apache::RegistryLexInfo;
@ISA = qw(Apache::RegistryNG);
Should the next version which supports mod_perl 1.x and 2.x:
o sub class ModPerl::RegistryBB, ModPerl::RegistryPrefork,
ModPerl::Registry ?
o Should it be configurable via a directive ?
o Should Apache2::RegistryLexInfo be made along side
instead of iffification ?
Thoughts ?
--
------------------------------------------------------------------------
"Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without."
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: Apache::Session's session size
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
c.w.huling@pobox.com wrote:
> Perrin Harkins writes:
>> On Wed, 2005-11-30 at 15:23 +1000, Badai Aqrandista wrote:
>>> I am using MySQL 4.1 on debian sarge. The type of the field that hold the
>>> session data is 'longtext'.
>> That holds a very large amount of data. You can't be overflowing that.
>>
>>> Patrick Michaud pointed me off the list that i
>>> should also bump max_packet_size up.
>> Probably, but that will not make you lose data.
>>
>>> It seems that this problem occurs in peak period, so it works in thousands
>>> of hits except once or twice. So it can't be scoping issue.
>> It certainly can be a scoping issue, but it could also be a locking
>> issue. Without seeing a test case that causes it, it's pretty hard to
>> guess.
>>
>>> Yes, that's why I am using Storable hooks to only serialize as small
>>> information as possible.
>> Storage of attributes in database columns should handle concurrency
>> better than anything using Storable because the locking and data
>> transfer will be more efficient.
>>
>
> I do believe setting the LongReadLen will fix your problem:
>
> eval {
> tie %session, 'Apache::Session::Oracle', $fdat{$SESSION_ID},
> { DataSource => GetDSN(),
> UserName => 'user',
> Password => 'pwd',
> Commit => 1,
> LongReadLen => 640000,
> };
> };
Isn't LongReadLen an Oracle only extension...... I don't believe MySQL
supports that.
--
------------------------------------------------------------------------
"Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without."
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: Apache::Session's session size
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2005-11-30 at 07:33 -0500, c.w.huling@pobox.com wrote:
> I do believe setting the LongReadLen will fix your problem
That only applies to Oracle, and they are using MySQL.
When LongReadLen is the problem, you don't just lose some data from a
session -- the entire session for that user becomes corrupted and can't
be read at all.
- Perrin
Re: Apache::Session's session size
Posted by c....@pobox.com.
Perrin Harkins writes:
> On Wed, 2005-11-30 at 15:23 +1000, Badai Aqrandista wrote:
> > I am using MySQL 4.1 on debian sarge. The type of the field that hold the
> > session data is 'longtext'.
>
> That holds a very large amount of data. You can't be overflowing that.
>
> > Patrick Michaud pointed me off the list that i
> > should also bump max_packet_size up.
>
> Probably, but that will not make you lose data.
>
> > It seems that this problem occurs in peak period, so it works in thousands
> > of hits except once or twice. So it can't be scoping issue.
>
> It certainly can be a scoping issue, but it could also be a locking
> issue. Without seeing a test case that causes it, it's pretty hard to
> guess.
>
> > Yes, that's why I am using Storable hooks to only serialize as small
> > information as possible.
>
> Storage of attributes in database columns should handle concurrency
> better than anything using Storable because the locking and data
> transfer will be more efficient.
>
I do believe setting the LongReadLen will fix your problem:
eval {
tie %session, 'Apache::Session::Oracle', $fdat{$SESSION_ID},
{ DataSource => GetDSN(),
UserName => 'user',
Password => 'pwd',
Commit => 1,
LongReadLen => 640000,
};
};
--
C Wayne Huling <c....@pobox.com>
Re: Apache::Session's session size
Posted by Jonathan <jv...@2xlp.com>.
On Nov 30, 2005, at 12:30 AM, Perrin Harkins wrote:
> It certainly can be a scoping issue, but it could also be a locking
> issue. Without seeing a test case that causes it, it's pretty hard to
> guess.
I'd suggest running data dumper and storing each iteration of a
'session' variable to a different text file -- then looking at them
and seeing how/why they're growing large.
At my last fulltime job, i had to fix a .NET project another agency
made. the devry graduate who programmed it saved a serialized
(encrypted) version of the session user as a hidden formfield to get
past browser cookies and an inability to munge server URIs. aside
from the user account info being obscenely big (40k ?! on first load)
-- he also had it save recursively.
ie:
session{user}
session{user{user}}
session{user{user}{user}}
so after 4 pageloads, you had a 200k html page because of that
serialized session. Not good , nor necessary.
Once, on something I quickly threw together, I stored the last
requested URL in the session var. a typo ended up in me essentially
appending the URL as a history, not replacing it entirely. a couple
hours of testing, and I had a 300k session variable and i couldn't
figure out why performance was degrading.
Re: Apache::Session's session size
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2005-12-01 at 09:20 +1000, Badai Aqrandista wrote:
> > > Patrick Michaud pointed me off the list that i
> > > should also bump max_packet_size up.
> >
> >Probably, but that will not make you lose data.
>
> But I guess in MySQL it does. Can anyone confirm this?
I would expect the insert to fail if you exceeded it. (The variable is
called max_allowed_packet, I believe.) If you have RaiseError on or you
check the return value of the insert, you should be able to see it
failing.
> >Storage of attributes in database columns should handle concurrency
> >better than anything using Storable because the locking and data
> >transfer will be more efficient.
>
> I mean the Storable used by A::S to serialize the data.
So am I. Because Apache::Session reads and writes the entire session
every time, it is transferring much more data than a more granular
approach with a normal table and updating separate columns. If it's in
multiple tables, it gets even better, since individual parts can be
locked separately (in a database that supports row-level locking, like
MySQL InnoDB).
> Sorry I can't create a test case because I don't really know what causes
> this.
Try writing a really large chunk of data to a session and see what
happens.
- Perrin
Re: Apache::Session's session size
Posted by Badai Aqrandista <ba...@hotmail.com>.
> > Patrick Michaud pointed me off the list that i
> > should also bump max_packet_size up.
>
>Probably, but that will not make you lose data.
But I guess in MySQL it does. Can anyone confirm this?
> > Yes, that's why I am using Storable hooks to only serialize as small
> > information as possible.
>
>Storage of attributes in database columns should handle concurrency
>better than anything using Storable because the locking and data
>transfer will be more efficient.
I mean the Storable used by A::S to serialize the data.
Sorry I can't create a test case because I don't really know what causes
this. That the size is just a guess. I am just looking for inspiration from
you guys because you all are very helpful.
Thanks for all who replied.
---
Badai Aqrandista
Cheepy (?)
_________________________________________________________________
SEEK: Over 80,000 jobs across all industries at Australia's #1 job site.
http://ninemsn.seek.com.au?hotmail
Re: Apache::Session's session size
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2005-11-30 at 15:23 +1000, Badai Aqrandista wrote:
> I am using MySQL 4.1 on debian sarge. The type of the field that hold the
> session data is 'longtext'.
That holds a very large amount of data. You can't be overflowing that.
> Patrick Michaud pointed me off the list that i
> should also bump max_packet_size up.
Probably, but that will not make you lose data.
> It seems that this problem occurs in peak period, so it works in thousands
> of hits except once or twice. So it can't be scoping issue.
It certainly can be a scoping issue, but it could also be a locking
issue. Without seeing a test case that causes it, it's pretty hard to
guess.
> Yes, that's why I am using Storable hooks to only serialize as small
> information as possible.
Storage of attributes in database columns should handle concurrency
better than anything using Storable because the locking and data
transfer will be more efficient.
- Perrin
Re: Apache::Session's session size
Posted by Badai Aqrandista <ba...@hotmail.com>.
Hi Perrin,
>What database are you using? I thought the default data types for most
>of them would hold a very large amount of data before having trouble. I
>suspect you are having locking problems or session data is not being
>written because the session object doesn't go out of scope.
I am using MySQL 4.1 on debian sarge. The type of the field that hold the
session data is 'longtext'. Patrick Michaud pointed me off the list that i
should also bump max_packet_size up.
It seems that this problem occurs in peak period, so it works in thousands
of hits except once or twice. So it can't be scoping issue.
>Even if the size of your session data isn't causing this lost data, it
>is a serious problem. When your session data is large, it makes
>everything slow, holds the locks longer, and hurts the performance of
>your site. You should consider putting that data into database tables
>instead and only loading it as needed.
Yes, that's why I am using Storable hooks to only serialize as small
information as possible.
---
Badai Aqrandista
Cheepy (?)
_________________________________________________________________
SEEK: Over 80,000 jobs across all industries at Australia's #1 job site.
http://ninemsn.seek.com.au?hotmail
Re: Apache::Session's session size
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2005-11-30 at 14:29 +1000, Badai Aqrandista wrote:
> I am experiencing intermittently missing session data. After weeks of
> investigation, we suspect the size of the data we put in the session as the
> culprit: it is too big.
What database are you using? I thought the default data types for most
of them would hold a very large amount of data before having trouble. I
suspect you are having locking problems or session data is not being
written because the session object doesn't go out of scope.
Even if the size of your session data isn't causing this lost data, it
is a serious problem. When your session data is large, it makes
everything slow, holds the locks longer, and hurts the performance of
your site. You should consider putting that data into database tables
instead and only loading it as needed.
- Perrin
Apache::Session's session size
Posted by Badai Aqrandista <ba...@hotmail.com>.
Hi All,
I am experiencing intermittently missing session data. After weeks of
investigation, we suspect the size of the data we put in the session as the
culprit: it is too big. So I am trying to fix it by adding Storable hooks
for objects stored in the session to create smaller serialized data.
I am just wondering has anyone experience problems with the size of the data
put in the session using Apache::Session? The problem is so critical yet so
intermittent that we can only fix it by trial and error.
Thank you...
---
Badai Aqrandista
Cheepy (?)
_________________________________________________________________
Start something musical - 15 free ninemsn Music downloads!
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=667&referral=HotmailTaglineNov&URL=http://www.ninemsn.com.au/startsomething