I mentioned something on the list a week ago about hash values being used
as last modification dates. This could still be a source of random delays
in processing. I've been tied up recently so I don't know if this has
already been solved with the new Monitor code. Here it is again:
On August 14, Stuart Roebuck wrote:
> In SitemapSource.java are the lines:
>
> // the event pipeline is cacheable
> // now calculate a last modification date
> String hashKey = pck.toString() + validity.toString();
> this.lastModificationDate = HashUtil.hash(hashKey);
>
> this is used in ProgramGeneratorImpl.java:
>
> /*
> * FIXME: It's the program (not the instance) that must
> * be queried for changes!!!
> */
> if (programInstance != null &&
> programInstance.modifiedSince(source.getLastModified())) {
> // Release the component.
> release(programInstance);
>
> consequently, any use of the ServerPages Generator which takes an input
> from within the sitemap (e.g. using a "cocoon:/" URI) will result in (on
> a practically random basis) certain XSP (et. al) pages being regenerated
> over and over again, and will potentially prevent updated XSP (et. al)
> from being properly regenerated.
On Tuesday, August 21, 2001, at 09:43 am, Morrison, John wrote:
>
>
>> -----Original Message-----
>> From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, 21 August 2001 9:22 am
>> To: Stefan Seifert
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: AW: [C2] Loadtest
>>
>>
>> On Mon, 20 Aug 2001 23:33:28 +0200, "Stefan Seifert"
>> <[EMAIL PROTECTED]> wrote:
>> Is your database running on the same machine with Cocoon? How much
>> time is spent executing the SQL queries? Maybe Cocoon is not the issue
>> here, but the database.
>>
>> Just an idea...
>
> Nice idea, but not true. I have the following hardware:
>
> 1. Development (personal) box:
> Webserver: Dual P2 300, 256M mem, several gig HDD, W2K, JDK 1.3.0,
> Catalina
> b6
> Database: using database from 2.
> 2. Development (testing) boxes:
> Webserver: P3 600, 64M mem, enough HDD, NT4 sp 6a, JDK 1.3.0, IIS4 +
> ServletExec 3.1
> Database: P3 600, 64M mem, enough HDD, NT4 sp 6a, SQLServer 7 (unknown
> sp)
> 3. QA (testing) boxes:
> Webserver: P3 600, 64M mem, enough HDD, NT4 sp 6a, JDK 1.3.0, IIS4 +
> ServletExec 3.1
> Database: P3 600, 64M mem, enough HDD, NT4 sp 6a, SQLServer 7 (unknown
> sp)
> 4. Deployment boxes:
> Webserver: DL380 (733MHz), 1G mem, *plenty* HDD, NT4 sp 6a, JDK 1.3.0,
> IIS4
> + ServletExec 3.1
> Database: DL320 (800MHz), 512M mem, *stacks* HDD, NT4 sp 6a, SQLServer
> 7
> (unknown sp)
>
> The *same* set of files (the only thing that changes from system to system
> is config) have been placed on *all* of the above systems. Response times
> from 1, 2, and 3 run from 47ms for simple, 'return this content' to a
> couple
> of quite rough (select top1 ... order by date desc) sql queries which
> typically run between 100ms & 1sec.
>
> On 4 (the big mothers) response times are from 5 to 7 seconds.
>
> I can't *do* anything but watch the big boxes (no dev capabilities) and
> the
> smaller boxes don't display the problem. Help? Suggestions? I'm only
> serializing xml and I'm only using the xsp generator (some pages with,
> some
> without esql) with no xslt in-between...
>
> I'm at a loss. I *was* getting similar response times until I upgraded
> the
> Cocoon release on the deployment boxes (I can't remember the version, but
> I
> could (if necessary) find out) to current 2.1. However, using the old
> release I was getting periodic slowdowns every 1.5 min for 30sec with a
> large(ish) concurrent hit.
>
> J.
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
