About a year ago we replaced a complex Java/XML middleware and webserver application tool with a much simpler single Perl/Apache web application server. Moving complex looping off the x86 Java system on to the back end IBM pSeries servers paid big dividends, with many of the steps taking seconds rather than minutes.
As part of the rebuild we also improved the programming at the SAP end as well as the web front end. When it went live people were happy, it was both a lot more stable and a lot faster. In the following 12 months we have had no problems - it is rock solid, but now it's not fast enough...
Today a contractor showed me how to do a SQL trace from SAP. The results showed that two queries were very slow - taking over 5 seconds on average. Without changing the quieries or the ABAP code we were able to tune the database to reduce the "cost" of these two queries. On a QA system with the same volume of data as live we cut the processing time of three steps down from over 30 seconds to less than five seconds. The two worst steps went from over 15 seconds each to under one second.
So now instead of SAP taking 30 times longer to get the data than Perl/TT2 took to render it, they now take about the same time. That's not to say that IE still wastes time with it's awful page rendering - but that's another story.
Re:sounds like
ajt on 2005-11-18T17:53:47
I have promised to write up the Perl side for brian d foy already... I just need to write it all up!
DB: basically SAP code gets data from the underlying DB using unoptimised SQL. Without touching the SAP standard SQL but tinkering with the indexing we got a massive performance boost.
Re:sounds like
Qiang on 2005-11-18T18:19:48
better hurry up with the story or it will be a two year old piece when it comes out;-)
