second when i host it using Apache.
The same command takes 10 seconds if i run my script on SimpleCGI Server of
python.
So, I can deduce that my apache is much faster. But i am not able to
understand why it is faster than the terminal itself.
Can someone tell me what happens when a script tries to run
On 23 November 2011 14:02, KingAndrew wrote:
> Thanks for the input. The whole question comes from my clients that have
> used corba/rmi for 15 years. Now that we are switching to
> Camel/ActiveMQ/JMS they all say:
> "It might scale better but I don't see how it can be as fast as Corba/RMI"
Ma
via Camel] <
ml-node+s465427n501612...@n5.nabble.com> wrote:
> Hi Andrew,
>
> Faster is a tricky term.
>
> You can say that runner A is faster than runner B, when you have them both
> run the same distance. In 100m A might be faster than B, but B might have
> more stamina and ma
If you can use asynchronous messaging, then messaging is typically
much faster (especially when you start to use transaction batching) as
you're not sat blocking waiting on RPC calls. e.g. on the consumer
side, the message broker will asynchronously stream messages into your
process spa
Hi Andrew,
Faster is a tricky term.
You can say that runner A is faster than runner B, when you have them both
run the same distance. In 100m A might be faster than B, but B might have
more stamina and manage to get first in a longer distance say 300m.
In your question I can see runner RMI and
Hi All,
I have a client that has an RMI/Corba/IIOP SOA application. For
scaleablity I plan on them using Camel/ActiveMQ. Scaling is good but it
must be as performant as the current RMI implementations.
So my question is: Is RMI inherently faster than JMS? I was thinking that
since we won
This discussion about IN, OUT, FAULT is moved to the topic we current
have on the dev forum.
This topic should be used for performance talk.
On Thu, Jul 9, 2009 at 7:44 PM, Claus Ibsen wrote:
> On Thu, Jul 9, 2009 at 4:50 PM, Hadrian Zbarcea wrote:
>> I hardly see a reason for the IN message to
On Thu, Jul 9, 2009 at 4:50 PM, Hadrian Zbarcea wrote:
> I hardly see a reason for the IN message to be mutable. Shouldn't it be
> read-only to start with?
> In my mind the IN is what you've been told, it's history, cannot be changed.
> If you want to echo something slightly different, you can al
I hardly see a reason for the IN message to be mutable. Shouldn't it
be read-only to start with?
In my mind the IN is what you've been told, it's history, cannot be
changed. If you want to echo something slightly different, you can
always produce the OUT you want (modified copy of the IN).
2009/7/9 Claus Ibsen :
> Hi
>
> See this wiki page for ideas on performance optimizations
> http://camel.apache.org/camel-2x-speed-optimizations.html
Copying Messages seems to be the big cost (particularly all those headers etc).
I wonder if we should use in the Pipeline a ReadOnlyMessageFacade
w
they will take several forms, but all
> are small. I parse a single line of text (eg from a log file or a text
> formatted socket), turn it into a small POJO, let esper work some magic on
> it, and I spit out correlation events probably in XML.
> --
> View this message in co
ation events probably in XML.
--
View this message in context:
http://www.nabble.com/Faster%21%21-tp24198880p24247565.html
Sent from the Camel - Users mailing list archive at Nabble.com.
way JMS and MINA routing with high speed would be on the radar as
high priority components to be as fast as possible.
BTW: The payloads you need yo send in real life with kind are they? Eg
small message, medium sized message, or big messages?
Are they byte[], stream based, text based or Objects?
A
r time, especially when you look at high
throughput
components like esper and mina.
I'll also see if I can hook up a profiler and see if I can provide
some
vision on what the bottlenecks I see are. If 1078 lands in a
snapshot I can
try it out to and report back.
--
View this message in
vision on what the bottlenecks I see are. If 1078 lands in a snapshot I can
try it out to and report back.
--
View this message in context:
http://www.nabble.com/Faster%21%21-tp24198880p24208422.html
Sent from the Camel - Users mailing list archive at Nabble.com.
benchmarks, and publish the numbers every release. On the
> prominent benchmarks, I'd love to see every release of Camel having a ticket
> or two addressing the top bottlenecks. Surely I'm not the only user out
> there interested in seeing a Camel get Faster.
> --
> View this m
benchmarks, I'd love to see every release of Camel having a ticket
or two addressing the top bottlenecks. Surely I'm not the only user out
there interested in seeing a Camel get Faster.
--
View this message in context:
http://www.nabble.com/Faster%21%21-tp24198880p24198880.html
Sent from the Camel - Users mailing list archive at Nabble.com.
17 matches
Mail list logo