I think I get a better picture. I was guessing it might be a Text To Speech application. I use to work on a wireless platform and one of the features we explored was converting emails to .wav files and send them to the user.
in my experience, the wav file would have been sent to a WAP phone with a modified WAP browser capable of playing wav files. That's the reason I assumed a stream. In your case, there's no streaming from the app server to other components, so I don't see any real risk. that doesn't mean there isn't. Just that I don't see any based on the info you've provided. chance are, you won't find a general purpose application server written in C++ that will provide significant performance benefit over the current crop of servlet containers. I know several people who have written EJB and servlet containers over the last 10 years. I have a cousin who has written EJB containers on 3 different occasions for telecom applications. In terms of network I/O performance. It should not be an issue. if concurrency is a concern, I would suggest looking at EmberIO or IBM's asyncIO. the only way you're going to know is to build a very quick prototype in 1-2 weeks and stress the heck out of it. I tend to take that approach and do the worse case scenario. If it passes the worse case scenario, you know it can only get better. good luck 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]
