Hello Peter, Nice to know that somebody replied. Was really desperate to get some inputs!! My replies are included below.
On Thu, 8 Jul 2004 21:39:23 -0400, Peter Lin <[EMAIL PROTECTED]> wrote: > from where I am sitting, sounds like the project doesn't have enough > information to make a good decision. Why move from MML/TCP to > VXML/HTTP? This is a requirement from some of our customers. They want to integrate with any 3rd party Media Server(which all talk VXML). > > if you read my performance article on the resources page, XML is very > CPU and memory intensive. Even with XStream java-xml binding library, > handling moderate concurrent load will easily consume 100% of the CPU. > if you're serious about using VXML/HTTP, you're going to have to use > some kind of hardware acceleration to get wire speed. 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. > > even without implementing a single line of code, I can tell you right > now it is going to be really hard scaling VXML/HTTP to handle 50 > concurrent streams. On a 3ghz cpu, 30 concurrent stream will consume > 100% of the CPU. With a 2.4ghz CPU, 10-15 concurrent xml parsers will > consume 60-75% of the CPU regardless of the platform. it doesn't > matter if you write it in C#, C++, C or Java. I keep a pretty close > watch on XML technology and most of the parsers today are about the > same. the differences are not significant to me. 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. > > given the primary limitation is CPU consumption, your options for > application server should be based on reliability, maturity and > toolset. If J2EE provides the features and scalability you need, then > use it. If writing your own application server in C++ is the best > option, then find two guys who have 10 years of experience writing > high performance app servers. 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). > > I would guess using servlets/jsp is the least of your concerns at this > point. Until you have the VXML driver written and know it's > performance characteristics, any decision on app server will be > premature. You may want to look at Xml Pull Parser3, XStream, Jixb, > XBis and the new xml stream parser. > > do a quick implementation for VXML and see what kind of performance > you get. if that is sufficient, you can move on. otherwise, you may > have to write a highly optimized VXML parser in C using a finite state > machine of some sort. good luck > > peter > 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) ? 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. > On Thu, 8 Jul 2004 18:19:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote: > > We implement a Messaging PLatform for Voice Applications. > > Our current platform has 2 Major Components as shown below:- > > > > Media Server <--- MML/TCP-IP ---> Application Server. > > > > We want to move to a new architecture for our Application Server where > > the interaction between App Server and Media Server is as shown > > below(i.e. based on VXML over HTTP) > > > > Media Server <--- VXML/HTTP ---> Application Server. > > > > To achieve this goal we need to implement an "VXML Document Server", > > which will generate VXML > > (Voice XML) pages based on the business logic & Data access layers > > within the Application server. > > > > We have 2 options to implement the VXML document Server:- > > > > 1) USing the J2EE presentation tier(i.e. JSP & Servlets) > > 2) Writing our own VXML generation module in C++ based(probably based > > on the JAVA Servlet paradigm). > > > > Our Factors while deciding between the 2 would be as follows:- > > > > 1) Performance(This is the key for us, we ezpecially need to know > > exactly how slow JAVA is as Compared to C++) > > 2) Integration with our Business logic & Data Access Layers.(All our > > business logic & data access is written in C/C++. Hence if we chose > > JAVA, then we might have to use JNI or make use of TCP/IP to > > communicate with our different Processes written in C/C++) > > 3) Ease of Future Change(We want to develop new Application Features > > Quickly & fast). > > 4) Fast & better Development environment. > > > > I am a proponent of the use of Tomcat Servlet Container and hence the > > use of J2EE front end for our module. But I was hoping to get some > > pointers from you all, just in case somebody might have implemented > > something similiar or might just have some inputs nevertheless. > > > > We are in a time crunch here, as we have to make a decision by next Monday end. > > > > Thanks in advance. > > > > Regards, > > > > Darshan. > > > > --------------------------------------------------------------------- > > 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]
