You may already have heard that SAPERION 6 has finally been released (hmmh, okay, it took a little longer than first expected, but we’re far from becoming an entrant of the Vaporware Awards…). With this new release, we have added more than a 100 new features, greatly overhauled the core architecture, and made available more than a 1,000 API calls in addition to those already available. While in the process of creating SAPERION’s newest ECM release, we also created SAPERIONforge, a SAPERION-centric platform for open source developers we intend to further expand in the future.
With SAPERION 6, we introduced the SAPERION Content Repository (SCR) infrastructure, which has been previously covered in this blog, based on Java and industry standards such as JCR, RMI, and Web Services. The good thing about SCR is that it is aimed to provide easy interoperability with SAPERION Classic environments (using Classic Connector) while at the same time enabling SAPERION users to work with industry standards such as the above.
While we were developing SCR, one of the foremost goals was to provide a release that would be rock stable and scalable from the beginning. We ran a lot of brute force tests (not necessarily identical to real world scenarios, e.g., one would not expect that a thousand users would log-in & start retrieving like hell from minute – in our case, second – one). Nonetheless, we ran those (and many other) tests. Given that SCR is JCR compliant, we have also been looking at other available implementations – after all, we wanted to know how we are faring compared to market companions (or, as others would say: competitors). To shed a little more light, we’d like to publish both our result for one of these brute force tests (figure 1) as well as one out of those other systems (figure 2).
The test emulates 1,000 users logging in at once and subsequent retrievals of a 100 documents (30k size) each. We think we do pretty well with an almost linear average retrieval time over the entire duration of the test, while the other implementation has some problems to achieve similar behavior. Btw, just for those questioning the method: we used a least square approach to generate the trendline in both diagrams.