Hi,
It is even worse for me... I dropped the tests regarding apache and I
tried tests directly against one ofbiz instance, without any apache in
front..using the same apache ab tool.
I never exceee 3-4 requests per second :(
I tried also to hit one static page and I reach arround 2000 req/sec and
for a page with one singe DB access through GenericDelegator I get aprox
1000 req/sec
Why for the the entire ecommerce application (actually for its main page
where I display few promo products, indeed with some processing for
PriceServices) I never get more than 34 requests per second?
regards,
Florin
Florin,
Have you tried using Apache's mod_proxy instead of mod_jk?
I'm not surprised that you get faster responses directly from Apache but 2-3
req/sec doesn't sound good for Tomcat either.
I'll try this same tool in our configuration and see what we get.
For us we configure mod_jk to communicate through the ofbiz AJP port.
We have also used mod_proxy which doesn't use AJP and goes directly to
Tomcat's http port (8080).
I'll run your recommended tool to see what gets better performance.
Brett
On Fri, Jan 29, 2010 at 6:07 AM, Florin Popa <[email protected]> wrote:
Hi,
It seems I was on a false track... the tests hits directly against ofbiz
(without Apache in front) did not work properly.. now they do and I only get
max 2-3 req.sec...
What could be wrong configured?
I tried similar hits against one simple tomcat and on 30 secs I reach 50000
req/sec.
I only touched this:
<thread-pool send-to-pool="pool"
purge-job-days="4"
failed-retry-min="3"
ttl="180000"
wait-millis="750"
jobs="500"
min-threads="50"
max-threads="500"
poll-enabled="true"
poll-db-millis="20000">
<run-from-pool name="pool"/>
</thread-pool>
What else needs to be configured for production load usage to reach more
requests per second?
The cache is also properly confgured
thanks,
Florin
Florin,
I'm not sure what you mean when you say "apache talke with ofbiz instances
via AJP rather than mod_jk". I thought mod_jk used AJP.
I would be interested if you find that AJP is a bottleneck. We use a
configuration with Apache on the front end and ofbiz on behind it. We use
mod_jk because it has a nice load balancer feature. We have also used
mod_proxy which doesn't use AJP but we haven't done any performance
testing
to compare the differences between the two.
Brett
On Thu, Jan 28, 2010 at 11:58 AM, Florin Popa <[email protected]
wrote:
I'll take a look ar Grinder, seems promising, thanks again.
Of course life is never easy :) now I have another problem... the network
admin configured 2 ofbiz instances having an apache in front of them as
balancer.. but apache "talks" with ofbiz instances via AJP rather than
mod_jk ..which seems to be a bottleneck..
Have you experienced that kind of things?
best regards,
Florin Popa
The Grinder is a nice tool for such things (and has a nice recording
proxy).
BTW, make sure to set your HTTP and thread pool sizes adequately for the
load you are planning on.
-David
On Jan 28, 2010, at 11:30 AM, Florin Popa wrote:
Thanks everyone for the help!
Today we succeeded port to geronimo transaction 2.1 as well as the
switch
from minerva to DBCP connection pool. It seems much better but I am not
fully content :)
Maybe because the automated testing tool I am using can not really hit
hard enough..
Any recommendation for such tools?
Of course upgrade to latest version was scheduled too but this would
take
longer..
Best regards,
Florin
You're using a quite old version of OFBiz with the Minerva connection
pool (I can tell from the stack trace you sent earlier). The Minerva
connection pool has some issues with resetting connections when there
are
errors, especially if there is any code that doesn't manage errors
well, but
also if there are network layer issues or other sorts of things... it
just
doesn't recover at all.
You could try making changes to use the Apache DBCP connection pool
that
we use now in OFBiz. To do so requires some low-level coding. You can
look
at the current code base for hints, but there is still some work.
There are no known workarounds to this issue for really high volume
sites, and for low-medium volume sites the workaround was to restart
the app
server(s) every day.
-David
On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:
I was just asking myself if someone encountered before such problems
on
older revisions..
Would be Geronimo ok to be used or shall I try something else?
regards,
Florin
I'm sorry the potential for problems with this approach is just too
large for me to be able to help you through it.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 27/01/2010, at 1:53 PM, Florin Popa wrote:
The attempt to update Ofbiz to recent revision is for the moment
(time limits) not possible.. there are so many differences... I am
even not
sure if bsh could work further instead of the newly groovy ?!
....also the
entity layer handling.. etc
So what I tried was to back port the transaction management -
latest
attempt is attached
