You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joshua McCulloch <co...@yahoo.com> on 2002/07/08 17:40:54 UTC
SQLTransformer
Hello,
I've been looking at page generating times with the
profiler. I am finding that SQLTransoformer is taking
a huge amount of time to do what I consider simple
queries. For example, a page that has two minor
queries takes about 130ms to complete.
Combined there are about 20 rows being returned. Would
you expect lower times?
Running:
Cocoon 2.0.2
Orion Server 1.5.4
Jdk 1.3.1
Mysql 3.23.49
MM jdbc drivers
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Here is one...
>
>xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
>
>If this idea picks up, SQLTransformer will be re-implemented as a set of
>tags (one tag?), and ESQL will be deprecated.
>
>:)
>
>
>PS SQLTransformer code might be messy. But functionality it provides is
>valuable to some (many?) users.
>
>Vadim
>
>
Looks like this:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/components/elementprocessor/
Personally I don't like the concept of generating XML at the transformer
level.
Can you give a use case where it is necessary?
-Andy
>
>
>>-Andy
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> Bertrand Delacretaz wrote:
>
> >On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
> >
> >>. . .
> >>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> >>newer releases, remove all SQLTransformer based samples (or provide
esql
> >>alternatives).
> >>
> >
> >(I have no formal voting rights here but)
> >-1
> >
> >Why remove a component that works?
> >This would certainly break some existing apps and annoy users.
> >
> >Maybe it could be marked "deprecated", as is done in java, meaning it
won't
> >be developed any further and is not recommended for new projects.
> >
> And that has worked so well in Java.... hehe. Its been deprecated for
> awhile. The documentation has said this. Officially
> Sun considers deprecated to mean that in future releases it may go
away.
> They're just lazy about doing it. This results in
> some things that work intermittantly which is the worst kind of bug.
>
> One reason is that its a maintenance drag, cocoon is undergoing some
> resonable re-engineering under the covers, along with Avalon.
Updating
> this deprecated class is a drag.
>
> As an alternative, perhaps we could move it off into something like
the
> scratchpad like a "oldstuff" or "compatibility-layer" kinda deal so
that
> it isn't included by default.
>
> Thoughts?
Here is one...
xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
If this idea picks up, SQLTransformer will be re-implemented as a set of
tags (one tag?), and ESQL will be deprecated.
:)
PS SQLTransformer code might be messy. But functionality it provides is
valuable to some (many?) users.
Vadim
> -Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> ESQL is certainly more developed, but it is not a replacement. Where
> in SQLTransformer do you suspect code rot? Have people been
> experiencing problems with it?
Open up the sourceode for the transformer, look at the amount of
repetitive code.. . The SQL Transformer is also some many factors slower
than ESQL. There is no shared source between them so fixes to each have
to be done seperately. For instance I needed support for big numbers, I
had to work in both places for consistancy.
-Andy
>
> --Greg Weinger
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Greg Weinger <gw...@itmedicine.net>.
Per Kreipke wrote:
>>The ESQL generator AFAIK supports everything one could need to do via
>>the SQLTransformer and there does not seem
>>to be a reason to continue to support both technologies.
>>
>>
>
>How can that be true? The transformation point in the pipeline is very
>different than a generator. For example, I can order transformations such
>that the SQL transformer comes between other transforms but you couldn't do
>that with a generator.
>
>Per
>
>
I have to second this; I have long disagreed with the implication, in
the documentation, that the SQLTransformer should be deprecated because
of ESQL.
It gives new users the sense that the Generation stage is the only place
to perform "heavy-duty" operations like data access. I think this
discourages creative thinking in using the Transformation stage to solve
problems. Just because M-V (of MVC fame) maps nicely to G-T, doesn't
mean that it should in every case, or that this is necessarily
preferable. A well-crafted Transformer can provide extremely effective
code reuse.
ESQL is certainly more developed, but it is not a replacement. Where in
SQLTransformer do you suspect code rot? Have people been experiencing
problems with it?
--Greg Weinger
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>How can that be true? The transformation point in the pipeline is very
>different than a generator. For example, I can order transformations such
>that the SQL transformer comes between other transforms but you couldn't do
>that with a generator.
>
>
Very few times is there a reason to build your query and pass it to the
transformation layer and I sure can't think of one. Secondly, this
"Transformer" is an extreme violation of the contract specified for a
Transformer. It more fits in with what a generator does.
-Andy
>Per
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Per Kreipke <pe...@onclave.com>.
> The ESQL generator AFAIK supports everything one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than a generator. For example, I can order transformations such
that the SQL transformer comes between other transforms but you couldn't do
that with a generator.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Bertrand Delacretaz wrote:
>On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>
>
>>. . .
>>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>newer releases, remove all SQLTransformer based samples (or provide esql
>>alternatives).
>>
>>
>
>(I have no formal voting rights here but)
>-1
>
>Why remove a component that works?
>This would certainly break some existing apps and annoy users.
>
>Maybe it could be marked "deprecated", as is done in java, meaning it won't
>be developed any further and is not recommended for new projects.
>
>
>
And that has worked so well in Java.... hehe. Its been deprecated for
awhile. The documentation has said this. Officially
Sun considers deprecated to mean that in future releases it may go away.
They're just lazy about doing it. This results in
some things that work intermittantly which is the worst kind of bug.
One reason is that its a maintenance drag, cocoon is undergoing some
resonable re-engineering under the covers, along with Avalon. Updating
this deprecated class is a drag.
As an alternative, perhaps we could move it off into something like the
scratchpad like a "oldstuff" or "compatibility-layer" kinda deal so that
it isn't included by default.
Thoughts?
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>. . .
> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> newer releases, remove all SQLTransformer based samples (or provide esql
> alternatives).
(I have no formal voting rights here but)
-1
Why remove a component that works?
This would certainly break some existing apps and annoy users.
Maybe it could be marked "deprecated", as is done in java, meaning it won't
be developed any further and is not recommended for new projects.
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [DOCUMENTATION ISSUE] Re: [PROPOSAL] Remove SQLTransformer in
2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
My bad...someone already did.
Andrew C. Oliver wrote:
> oh and can we remove the "its deprecated" notation from the
> documentation.
>
> Time permitting, I'll attempt to resolve why it is so slow by comparison.
>
> -Andy
>
> Carsten Ziegeler wrote:
>
>> Andrew C. Oliver wrote:
>>
>>
>>> Hi All,
>>>
>>> Backward compatibility among minor revisions is generally a smart
>>> and good thing to do. However, there does
>>> become a point where it grows six legs and starts biting you.
>>>
>>> The ESQL generator AFAIK supports everything one could need to do
>>> via the SQLTransformer and there does not seem
>>> to be a reason to continue to support both technologies.
>>>
>>> IMHO, while the code quality of the ESQL stylesheet is relatively
>>> low, the quality of the SQLTransformer is lower probably due to code
>>> rot and negative evolutionary pressures.
>>>
>>> I would suppose the SQLTransformer being largely a Cocoon 1.x
>>> construct is reasonable slow and my own unscientific benchmarking
>>> seems to confirm this.
>>>
>>> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>> newer releases, remove all SQLTransformer based samples (or provide
>>> esql alternatives).
>>>
>>>
>>
>> -10
>>
>> The SQLTransformer provides a very good alternative to ESQL, it is in
>> some use cases more flexible as it is a transformer and not a generator.
>> And you don't need XSP to use it.
>>
>> The SQLTransformer in its current state is not a 1.x construct, it has
>> been redesigned several times and works afaik absolutely perfect. It
>> is used in production environments without any problems.
>>
>> Carsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[DOCUMENTATION ISSUE] Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
oh and can we remove the "its deprecated" notation from the documentation.
Time permitting, I'll attempt to resolve why it is so slow by comparison.
-Andy
Carsten Ziegeler wrote:
>Andrew C. Oliver wrote:
>
>
>>Hi All,
>>
>>Backward compatibility among minor revisions is generally a smart and
>>good thing to do. However, there does
>>become a point where it grows six legs and starts biting you.
>>
>>The ESQL generator AFAIK supports everything one could need to do via
>>the SQLTransformer and there does not seem
>>to be a reason to continue to support both technologies.
>>
>>IMHO, while the code quality of the ESQL stylesheet is relatively low,
>>the quality of the SQLTransformer is lower probably due to code rot and
>>negative evolutionary pressures.
>>
>>I would suppose the SQLTransformer being largely a Cocoon 1.x construct
>>is reasonable slow and my own unscientific benchmarking seems to confirm
>>this.
>>
>>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>newer releases, remove all SQLTransformer based samples (or provide esql
>>alternatives).
>>
>>
>>
>-10
>
>The SQLTransformer provides a very good alternative to ESQL, it is in
>some use cases more flexible as it is a transformer and not a generator.
>And you don't need XSP to use it.
>
>The SQLTransformer in its current state is not a 1.x construct, it has
>been redesigned several times and works afaik absolutely perfect. It
>is used in production environments without any problems.
>
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>It is remarkably slower than ESQL. Okay if you feel this strongly about
>>it then thats fine. Would you
>>be against refactoring the two and moving the common constructs to
>>common classes as Vadim suggested?
>>
>>
>>
>No, refactoring sounds like a good idea as long as the SQLTransformer
>is not dependend on any XSP stuff.
>
>
I would consider that a given. Great then.
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
> >-10
> >
> >The SQLTransformer provides a very good alternative to ESQL, it is in
> >some use cases more flexible as it is a transformer and not a generator.
> >And you don't need XSP to use it.
> >
> >The SQLTransformer in its current state is not a 1.x construct, it has
> >been redesigned several times and works afaik absolutely perfect. It
> >is used in production environments without any problems.
> >
> >
> It is remarkably slower than ESQL. Okay if you feel this strongly about
> it then thats fine. Would you
> be against refactoring the two and moving the common constructs to
> common classes as Vadim suggested?
>
No, refactoring sounds like a good idea as long as the SQLTransformer
is not dependend on any XSP stuff.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>
>>
>-10
>
>The SQLTransformer provides a very good alternative to ESQL, it is in
>some use cases more flexible as it is a transformer and not a generator.
>And you don't need XSP to use it.
>
>The SQLTransformer in its current state is not a 1.x construct, it has
>been redesigned several times and works afaik absolutely perfect. It
>is used in production environments without any problems.
>
>
It is remarkably slower than ESQL. Okay if you feel this strongly about
it then thats fine. Would you
be against refactoring the two and moving the common constructs to
common classes as Vadim suggested?
-Andy
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
>
> Hi All,
>
> Backward compatibility among minor revisions is generally a smart and
> good thing to do. However, there does
> become a point where it grows six legs and starts biting you.
>
> The ESQL generator AFAIK supports everything one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
>
> IMHO, while the code quality of the ESQL stylesheet is relatively low,
> the quality of the SQLTransformer is lower probably due to code rot and
> negative evolutionary pressures.
>
> I would suppose the SQLTransformer being largely a Cocoon 1.x construct
> is reasonable slow and my own unscientific benchmarking seems to confirm
> this.
>
> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> newer releases, remove all SQLTransformer based samples (or provide esql
> alternatives).
>
-10
The SQLTransformer provides a very good alternative to ESQL, it is in
some use cases more flexible as it is a transformer and not a generator.
And you don't need XSP to use it.
The SQLTransformer in its current state is not a 1.x construct, it has
been redesigned several times and works afaik absolutely perfect. It
is used in production environments without any problems.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Hi All,
Backward compatibility among minor revisions is generally a smart and
good thing to do. However, there does
become a point where it grows six legs and starts biting you.
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
to be a reason to continue to support both technologies.
IMHO, while the code quality of the ESQL stylesheet is relatively low,
the quality of the SQLTransformer is lower probably due to code rot and
negative evolutionary pressures.
I would suppose the SQLTransformer being largely a Cocoon 1.x construct
is reasonable slow and my own unscientific benchmarking seems to confirm
this.
I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
newer releases, remove all SQLTransformer based samples (or provide esql
alternatives).
Thoughts?
-Andy
Tom Klaasen wrote:
> Joshua McCulloch wrote:
>
>> The queries are definitely not taking 130ms outside of
>> cocoon.
>>
>
> Can you put numbers on this? How much does it take to do the same
> queries in a simple java program? (setup connections, start timer,
> execute queries, stop timer)
>
> And on another note: does it also takes 130 ms if the SQLTransformer
> is already executed some times? The first time, you have overhead in
> creating connections etc, while after some times, the connections are
> taken from a pool.
>
>>
>> What do you mean by turning off debugging? I've
>> changed the logging status to ERROR, and saw some
>> improvement. What did you turn off, and how did you do
>> so?
>>
>
> That's what I meant: change logging status to ERROR. I'm not sure
> though if this can still be done on one place, or if there are more
> places nowadays where you can reduce the logging level (yeah, I know,
> my in-depth days of Cocoon are some time behind me already. I hope I
> can get to work on some Cocoon project again, but that won't be in the
> near future).
>
>> Thanks! :)
>>
>
> np, that's what we're here for ;)
>
> tomK
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SQLTransformer
Posted by Tom Klaasen <to...@pandora.be>.
Joshua McCulloch wrote:
>The queries are definitely not taking 130ms outside of
>cocoon.
>
Can you put numbers on this? How much does it take to do the same
queries in a simple java program? (setup connections, start timer,
execute queries, stop timer)
And on another note: does it also takes 130 ms if the SQLTransformer is
already executed some times? The first time, you have overhead in
creating connections etc, while after some times, the connections are
taken from a pool.
>
>What do you mean by turning off debugging? I've
>changed the logging status to ERROR, and saw some
>improvement. What did you turn off, and how did you do
>so?
>
That's what I meant: change logging status to ERROR. I'm not sure though
if this can still be done on one place, or if there are more places
nowadays where you can reduce the logging level (yeah, I know, my
in-depth days of Cocoon are some time behind me already. I hope I can
get to work on some Cocoon project again, but that won't be in the near
future).
>Thanks! :)
>
np, that's what we're here for ;)
tomK
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SQLTransformer
Posted by Joshua McCulloch <co...@yahoo.com>.
The queries are definitely not taking 130ms outside of
cocoon.
What do you mean by turning off debugging? I've
changed the logging status to ERROR, and saw some
improvement. What did you turn off, and how did you do
so?
Thanks! :)
- Josh
--- Tom Klaasen <to...@pandora.be> wrote:
> Hi Joshua,
>
> Did you perform the same test outside of cocoon? You
> should check how
> long it actually takes for MySql to answer your
> query. If this is much
> faster than those 130 ms, there might be a problem.
>
> Also note that turning of debugging in Cocoon has
> given me a 10 times
> speedup once. Maybe you don't consider 13ms for 2
> queries so slow ;-)
>
> Please keep us posted on your findings,
> tomK
>
>
> Joshua McCulloch wrote:
>
> >Hello,
> >
> >I've been looking at page generating times with the
> >profiler. I am finding that SQLTransoformer is
> taking
> >a huge amount of time to do what I consider simple
> >queries. For example, a page that has two minor
> >queries takes about 130ms to complete.
> >
> >Combined there are about 20 rows being returned.
> Would
> >you expect lower times?
> >
> >Running:
> >Cocoon 2.0.2
> >Orion Server 1.5.4
> >Jdk 1.3.1
> >Mysql 3.23.49
> >MM jdbc drivers
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Sign up for SBC Yahoo! Dial - First Month Free
> >http://sbc.yahoo.com
> >
>
>---------------------------------------------------------------------
> >Please check that your question has not already
> been answered in the
> >FAQ before posting.
> <http://xml.apache.org/cocoon/faq/index.html>
> >
> >To unsubscribe, e-mail:
> <co...@xml.apache.org>
> >For additional commands, e-mail:
> <co...@xml.apache.org>
> >
> >
> >
> >
> >
>
>
>
>
>
---------------------------------------------------------------------
> Please check that your question has not already
> been answered in the
> FAQ before posting.
> <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail:
> <co...@xml.apache.org>
> For additional commands, e-mail:
> <co...@xml.apache.org>
>
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SQLTransformer
Posted by Tom Klaasen <to...@pandora.be>.
Hi Joshua,
Did you perform the same test outside of cocoon? You should check how
long it actually takes for MySql to answer your query. If this is much
faster than those 130 ms, there might be a problem.
Also note that turning of debugging in Cocoon has given me a 10 times
speedup once. Maybe you don't consider 13ms for 2 queries so slow ;-)
Please keep us posted on your findings,
tomK
Joshua McCulloch wrote:
>Hello,
>
>I've been looking at page generating times with the
>profiler. I am finding that SQLTransoformer is taking
>a huge amount of time to do what I consider simple
>queries. For example, a page that has two minor
>queries takes about 130ms to complete.
>
>Combined there are about 20 rows being returned. Would
>you expect lower times?
>
>Running:
>Cocoon 2.0.2
>Orion Server 1.5.4
>Jdk 1.3.1
>Mysql 3.23.49
>MM jdbc drivers
>
>__________________________________________________
>Do You Yahoo!?
>Sign up for SBC Yahoo! Dial - First Month Free
>http://sbc.yahoo.com
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
>To unsubscribe, e-mail: <co...@xml.apache.org>
>For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SQLTransformer
Posted by Joshua McCulloch <co...@yahoo.com>.
<jdbc name="myhms-datasource"
logger="core.datasources.myhms-datasource">
<pool-controller min="5" max="10"/>
<dburl>jdbc:mysql://localhost/ccc</dburl>
<user>aaa</user>
<password>bbb</password>
</jdbc>
According to the datasource configuration in
cocoon.xconf, it should be pooling. The logs
(core.log) seem to say its pooling:
ApplicationServerThread/LogKitLogger: Got a
org.apache.avalon.excalibur.datasource.JdbcConnection
from the pool.
ApplicationServerThread/LogKitLogger: Put a
org.apache.avalon.excalibur.datasource.JdbcConnection
back into the pool.
Are there any other ways to determine if pooling is
truly being used? I guess I could look around in
MySQL, I'm sure it keeps logs of connections
somewhere..
Thanks,
Josh
--- Bruno Dumon <br...@outerthought.org> wrote:
>
> Are you sure you are using connection pooling? If
> not, then the above
> times seem reasonable.
>
> --
> Bruno Dumon
> http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence
> Support Center
> bruno@outerthought.org
>
>
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SQLTransformer
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2002-07-08 at 17:40, Joshua McCulloch wrote:
> Hello,
>
> I've been looking at page generating times with the
> profiler. I am finding that SQLTransoformer is taking
> a huge amount of time to do what I consider simple
> queries. For example, a page that has two minor
> queries takes about 130ms to complete.
>
> Combined there are about 20 rows being returned. Would
> you expect lower times?
>
Are you sure you are using connection pooling? If not, then the above
times seem reasonable.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: SQLTransformer
Posted by Luca Morandini <lu...@tin.it>.
Joshua,
have you profiled the same queries using ESQL ?
It could be useful having such a benchmark.
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Joshua McCulloch [mailto:cocoonjosh@yahoo.com]
> Sent: Monday, July 08, 2002 5:41 PM
> To: cocoon-users@xml.apache.org
> Subject: SQLTransformer
>
>
> Hello,
>
> I've been looking at page generating times with the
> profiler. I am finding that SQLTransoformer is taking
> a huge amount of time to do what I consider simple
> queries. For example, a page that has two minor
> queries takes about 130ms to complete.
>
> Combined there are about 20 rows being returned. Would
> you expect lower times?
>
> Running:
> Cocoon 2.0.2
> Orion Server 1.5.4
> Jdk 1.3.1
> Mysql 3.23.49
> MM jdbc drivers
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>