Paul Brown wrote: > > Stefano -- > > Are you using Xalan J2.2.Dx within Cocoon? If so, that may account for it. > Depending on the application, we've observed SIGNIFICANT performance > problems with Xalan J2.2.Dx, especially where a transition DOM<->DTM occurs.
I'm not the one who made the tests. Maybe this is useful for others. > -- Paul > > > -----Original Message----- > > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > Sent: Friday, November 30, 2001 11:38 AM > > To: Apache Cocoon > > Cc: Michael Homeijer > > Subject: Cocoon 2.0 Scalability Disappointment > > > > > > Michael told me privately the numbers that he has been experiencing > > along with a description of his environment and I now agree with him, we > > have a serious scalability problem. > > > > He refers to 2.0RC2 but since nothing that could improve performance > > changed between 2.0 and 2.0RC2, I think it's still up there. > > > > For "serious", I mean something important that should be fixed ASAP, > > otherwise, Cocoon 2.0 will rarely have any use in high-load > > environments. > > > > The numbers say, more or less, than the same functionality ported from > > Cocoon 1.8.2 to Cocoon 2.0RC2 resulted in 20 times slower performance! > > > > Yes, guys, we're not talking about 20% slower but 2000% slower. > > > > WAIT, STOP, SIT DOWN! > > > > Before you rush to your boss to tell that Cocoon 2.0 sucks and you > > shouldn't place your million-dollars worth project on it, let me explain > > what I believe the problem is. > > > > 1) their Cocoon 1.8.2 application has been up for a long time and they > > carefully tuned the system for it. Their Cocoon 2.0RC2 version is an > > early implementation. > > > > 2) they admit the Cocoon 2.0 cache system is likely to provide huge > > benefits for them, but they are not sure they are using it properly. > > > > 3) they don't use a transparent proxy on top so the Cocoon cache is > > continously stressed. > > > > 4) they report much better "perceived" performance on a single browsing > > experience: this seems to show that Cocoon 2.0 isn't slow by itself, but > > there is an hidden bottleneck someplace. > > > > 5) they use XSP. I'm aware of performance issues with XSP load and > > execution under heavy load (some forgotten locking or synchronized > > method?). This is the place where I'd concentrate profiling effort. > > > > Net Result: I think Cocoon 2.0, as it stands, doesn't scale, but the > > data provided it's not sufficient to understand *what* slows Cocoon > > down. > > > > Michael, I'd love if you guys could perform some more load tests for us: > > > > 1) disable logging. If log is DEBUG, it could generate Gigabytes of > > information and disks could become the bottleneck. > > > > [I think log might be the bottleneck] > > > > 2) disable resource reloading. Same as above, the disk I/O system could > > become the bottleneck. > > > > 3) try to come up with some logarithmic stress tests: 1 req/sec, 2 > > req/sec, 4 req/sec, 8, 16, 32, 64, until your machines saturate. > > > > 4) turn the cache off/on. [this, compared to the logaritmic approach > > should give us information on the caching system] > > > > 5) try to get the generated source code of one of your XSP, compile it > > as a generator and use it as a normal generator instead. [this should > > remove the XSP loading/handling phase] > > > > With this data we will know where the problem is and if it really > > resides in Cocoon. > > > > -- > > Stefano Mazzocchi One must still have chaos in oneself to be > > able to give birth to a dancing star. > > <[EMAIL PROTECTED]> Friedrich Nietzsche > > -------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
