Hi Peter,
I suppose there is some confusion.
I believe you got it right, that the Media Server is the one which
will interpret the VXML pages and not the Application server.
But these VXML pages wont have any SPEECH in it. Instead they have
specific TAGS related to speech
for e.g a snipplet from a VXML page would look like as below:
<prompt>
Welcome to the Message Center, Please Enter your password.
</prompt>
Note that the prompt is in just TEXT format. These pages when
interpreted on the Media Server side will resut into SPEECH being
heard by the end user by the use of TTS(text to speech server).
Thus there is completely no streaming of Speech between the Media
Server and Application Server. (if need to pass in some specific
speech file, the Media Server will just recieve a file Handle, maybe
an ID which will map to some file on the NAS which is shared by
Application Server & Media Server)
I hope that I have not confused more :)
For the context related to the performance impact of JAVA, its mainly
CPU operations. What we essectially want to know is whether
introduction of JAVA into our platform(which is completely C/C++)
bring about significant load on the resources(mostly CPU power). And
if yes how much ? Would it be some thing that I need to be worried
about ? Also, can we say that the use of JIT in JAVA can nullify
(within reasonable limits) the overhead of JVM in JAVA and at what
cost.
Also, instead of JNI what do you think about the use of
Sockets(TCP/IP) to communicate with our C/C++ processes(which any way
listen on some TCP/IP socket). Would you expect performance
degradation, by use of sockets through JAVA and if yes is there any
reasonable and objective measurements ?
Also, just in case, do you know of any objective comparision of JAVA & C/C++ ?
I could not find one on Google, which was not Objective enough.
Thanks again for all you help, it was really valuable...
Regards,
Darshan Rawal.
On Thu, 8 Jul 2004 21:23:52 -0500, Peter Lin <[EMAIL PROTECTED]> wrote:
> On Thu, 8 Jul 2004 18:59:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote:
> > Hello Peter,
> >
> >
> > I completely agree on this, but this interpretation of VXML pages is
> > going to happen on the Media Server side. Hence as of now I am just
> > concerned with generation of VXML pages and transporting them to the
> > Media Server, where the CPU intensive XML parsing is going to happen.
>
> ok, so if I understand the setup correctly. the app server will only
> generate VXML and not consume it. If that is the case, CPU usage
> should not be an issue. For detailed information about XML generation
> performance, google for XML articles by Dennis Sosnoski. He has
> written up detailed articles in the past on xml parsers and xml
> binding parser.
>
> > We are currently utilizing a 650MHz Sun Sparc Blade & Solaris 8 Core
> > OS, and it will remain the same for the next release, hence I know
> > that CPU load will be a reasonable main concern.
> >
>
> Having done stress testing with XML on Solaris systems: 280R, X1,
> UltraSparc5, as long as you're not consuming XML, CPU should not be an
> issue. Since XML is very verbose and Sun blades typically come with 2
> or 4 ethernet ports, I would recommend separating the network traffic
> so the XML uses a dedicated router to the media server.
>
> >
> > Our entire Engineering team has reasonablly well knowledge of
> > C++/C.(not so much of JAVA).Also, complete development is going to be
> > done by our team.
> > We are a part of the architecture team which has to decide the
> > approach to take, and I was just looking for some pointer on that
> > issue(especially related to the performance implications for JAVA).
> >
>
> when you say performance implications, what do you mean? high
> concurrent load? memory usage? I/O? threading? the context plays a big
> factor in whether or not there will be any issues.
>
> > An prototype of a VXML browser in the Media Server has already been
> > implemeted. It does have some performance issues. But, as I said
> > earlier this is not our main concern as of now. The questions that we
> > have related to taking the approaches are as follows:-
> >
> > 1) Would JAVA be a performance hit in terms of CPU
> > utilization(especially bcos of the JVM) ? Note that our VXML document
> > server is not the one doing a lot of CPU intensive operations, it will
> > be our legacy application written in C/C++.
> > Also, we are not doing significant CPU intensive operation like math
> > operations, number crunching, encryption, etc. Would JIT provide
> > reasonable performance compared to C/C+, by probably consuming more
> > memory(which we can spare) ?
>
> since the app server is just producing the content, my guess is it's
> unlikely there will be any issues beyond concurrency requirements.
> since it's media, I'm assuming the servlet will produce a stream of
> data. You're probably going to have to use some sort of stream
> conversion to reduce memory usage. Regardless of the storage medium, I
> wouldn't recommend using DOM and would strongly suggest using the new
> xml stream parser/api.
>
> >
> > 2) How involving is the work related to integrating a JSP/Servlet
> > based front end to legacy C/C++ code using JNI(debugging, performance
> > issues ??) and/or TCP/IP sockets(performance Hit) ?
> >
> > Thanks & Regards,
> >
> > - Darshan.
>
> I have no experience in JNI beyond reading examples and looking at the
> API/specs, so I can't provide anything useful there. You definitely
> can get good performance with JNI. Many servlet and EJB containers use
> JNI to call native network libs. Resin, weblogic and websphere all use
> it, so JNI won't be an issue. I hope that helps.
>
> peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
