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]
