by the way, there is a standard Text To Speech API and reference implementing for Java. I know Leap Wireless uses that with an EJB container for some internal applications. I can't go into details, but I do know of cases where it scales just fine.
peter On Fri, 9 Jul 2004 11:19:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
