Chris Tweedie of our ERDAS Australia Region has recently reproduced the FOSS4G raster imagery performance benchmark tests using ERDAS APOLLO to compare the results and has published them on his blog:
Here are the Results of ERDAS APOLLO 2010 using the FOSS3G Test Sceneario
We've all been really busy with the Recent APOLLO 2010 Release, but Chris made it a priority to get these numbers completed and published. Nice work Chris!
Chris did a great job of providing graphs for Image Format performance for each Map Server and graphs for Throughput and Response Times for each format with each Map Server to make it comparable by Server or by Format/Server.
Some analysis of the results:
1. ECW imagery format is a "performance purpose" built imagery format. The throughput of ERDAS APOLLO with the ECW format is 2.5 the Open Source Servers at a 150 user load and can support a much higher load than 150 which wasn't represented in the this test scenario. The throughput curve had a steep positive slope even at 150 users where the other servers were peaked out with throughput at the 150 user measurement.
2. ERDAS APOLLO outperformed each Open Source server on every image format with the highest Throughput (transactions/second) and lowest Average Response Times (the time that it takes to get the image on your map). ERDAS APOLLO outperformed open source with every image format in the test.
ERDAS will be providing several webinars and whitepapers regarding the subject of "Raster Imagery Performance" to showcase the ERDAS APOLLO 2010 and it's performance capabilities.
Keep in mind that these numbers do not even showcase our faster imagery protocols that we provide with ERDAS APOLLO....
ECWP and our Optimized Tile Delivery are MUCH faster and support much higher user loads compared to the WMS protocol (THOUSANDS of users on a standard server). In short, we can produce maps MUCH FASTER than these numbers published with the "slowest" protocol provided by the APOLLO 2010.
Good work again Chris...
Showing posts with label Enterprise. Show all posts
Showing posts with label Enterprise. Show all posts
Thursday, December 17, 2009
Friday, May 15, 2009
Is the Geospatial World devoid of Performance Benchmarks??
Why are performance benchmarks so elusive for enterprise geospatial software?? Every Request for Proposals for enterprise geospatial software requires some level of "performance" to be reported. Commonly RPF's request the expected number of concurrent users, throughput and "load" the system can handle and indirectly a hardware set to be recommend based on a purported number of users that will be using the system.
Here at ERDAS, we invested in HP LoadRunner to design an enterprise performance testing system that is the best I've ever seen in my history with enterprise software. Unlike many vendors, we don't report "predictive" numbers, we produce and report ACTUAL performance numbers on real world enterpise systems under design! We of course use the testing setup internally to determine 'things to improve' and the impact of individual features (i.e. portrayal or reprojection) vs. a known baseline. Just to be forwarned, the setup was not cheap and it was also not easy to figure out how to properly implement, but the stability, flexibility, repeatability of test "scenarios" and RESULTS produced are AWSOME!
All I know is that I "FROTH" at the opportunity to stand APOLLO up to any system on the market today! We've "handily" beat out several competitors in "head to head" evaluations and always meet our documented performance results. I attribute this to our investment in performance testing setups and required performance test scenarios to pass before every release. The testing setup has proven INVALUABLE in succinctly diagnosing performance issues, ensuring our performance at release time is to our standards and report to customers the performance they should expect...and MEET that expectation!
Here at ERDAS, we invested in HP LoadRunner to design an enterprise performance testing system that is the best I've ever seen in my history with enterprise software. Unlike many vendors, we don't report "predictive" numbers, we produce and report ACTUAL performance numbers on real world enterpise systems under design! We of course use the testing setup internally to determine 'things to improve' and the impact of individual features (i.e. portrayal or reprojection) vs. a known baseline. Just to be forwarned, the setup was not cheap and it was also not easy to figure out how to properly implement, but the stability, flexibility, repeatability of test "scenarios" and RESULTS produced are AWSOME!
All I know is that I "FROTH" at the opportunity to stand APOLLO up to any system on the market today! We've "handily" beat out several competitors in "head to head" evaluations and always meet our documented performance results. I attribute this to our investment in performance testing setups and required performance test scenarios to pass before every release. The testing setup has proven INVALUABLE in succinctly diagnosing performance issues, ensuring our performance at release time is to our standards and report to customers the performance they should expect...and MEET that expectation!
Monday, April 13, 2009
SOAP vs. REST in Geospatial Applications
It's interesting to see the decision making process at organizations evaluating geospatial technologies. One area that I see a lot of "effort" from an IT and developer stakeholders in Geospatial Software Purchases is in the form, function and ROI of the technologies REST or SOAP. This is being driven on the enterprise side of the house where these technologies are essentially thier choice of which to invest in.
The ESRI Developer Summit Keynote provides a good technology overview by Dave Chappel on "SOAP vs. REST". Probably for people at a decision maker level trying to understand the technology and "keywords" or end users trying to get a better understanding of the technology, this is a good starting point.
Two areas that is always analyzed and heavily weighed in any evaluations is INTEROPERABILIY and SECURITY, and this is where SOAP clearly becomes the "leader of the pack" in technologies today. This is with any technology that these two categories are scrutinized. The requirement for proprietary REST client interfaces is such a drawback of the technology. Why would I want to have to integrate a proprietary interface in everything that I want geospatial data and have a proprietary client interface integration effort to 'work' with my GI and services? The pushback in that process is definately "loud and clear" from the market. In terms of security, you CAN secure REST endpoints, this is not a problem, but a lack of any standard to do so and/or the client interfaces proper ability to handle security rhealms must be accounted for, you shouldn't have to 'poke' at it to find out if it works. Again, same theme, proprietary is a big blocking issue there.
Mr. Chappell raises a good point in that SOAP is not "easy" to manage from the client side of the house as managing XML isn't the easiest or most eloquent. Fortunately in the GI space, everybody already supports the standardized services (WMS, WCS, WFS, etc, etc), so the "effort" and ability to handle it with standard interoperable client interfaces is widely prolifererated and highly available, so i think that point is rather 'mute'.
Don't get me wrong, REST is a GREAT technology, it simply needs some standards bodies to define how and where they will be used to get the same ROI and proliferation as the well defined SOAP services today. This process is firing up with the OGC right now. Hope the conjur up something useful with that... :)
The ESRI Developer Summit Keynote provides a good technology overview by Dave Chappel on "SOAP vs. REST". Probably for people at a decision maker level trying to understand the technology and "keywords" or end users trying to get a better understanding of the technology, this is a good starting point.
Two areas that is always analyzed and heavily weighed in any evaluations is INTEROPERABILIY and SECURITY, and this is where SOAP clearly becomes the "leader of the pack" in technologies today. This is with any technology that these two categories are scrutinized. The requirement for proprietary REST client interfaces is such a drawback of the technology. Why would I want to have to integrate a proprietary interface in everything that I want geospatial data and have a proprietary client interface integration effort to 'work' with my GI and services? The pushback in that process is definately "loud and clear" from the market. In terms of security, you CAN secure REST endpoints, this is not a problem, but a lack of any standard to do so and/or the client interfaces proper ability to handle security rhealms must be accounted for, you shouldn't have to 'poke' at it to find out if it works. Again, same theme, proprietary is a big blocking issue there.
Mr. Chappell raises a good point in that SOAP is not "easy" to manage from the client side of the house as managing XML isn't the easiest or most eloquent. Fortunately in the GI space, everybody already supports the standardized services (WMS, WCS, WFS, etc, etc), so the "effort" and ability to handle it with standard interoperable client interfaces is widely prolifererated and highly available, so i think that point is rather 'mute'.
Don't get me wrong, REST is a GREAT technology, it simply needs some standards bodies to define how and where they will be used to get the same ROI and proliferation as the well defined SOAP services today. This process is firing up with the OGC right now. Hope the conjur up something useful with that... :)
Thursday, February 28, 2008
Enterprise Software
I hear the term "enterprise software" used extremely "loose" in the geospatial software market. Now to elude to the term not being used "correctly"...I'm forced to define "what is enterprise software".
Here is a stab at "enterprise software" on wikipedia. I love wikipedia, but that reading is "wikidiculous". "Enterprise Software" is not defined by "solving" an enterprise (entire business level) problem, that would allow almost any software be enterprise. All business units need to "compress" files to make them smaller for distributing them in e-mail...does that make WinZip an "enterprise software"?
There are lots of search engine permutations that you can attempt to find information on "enterprise", "enterprise computing", "enterprise requirements", "what is enterprise"...all leading to a dead end of NO DEFINITION. Its strange that we can probably name 5 enterprise class softwares off the top of our head (I would say Oracle, SAP, E-Bay, Google, and of course, the Leica Image Manager). What "separates" these softwares from the non enterprise class?
...lets start with defining "properties" of enterprise software so we can come up with a "Websters-like" Dictionary definition.
1. Collaborative - all enterprise softwares are multi-user by design. The architecture must support many concurrent user connections and the ability to process each individual users requested as a single transactional unit. This multi user ability allows the users as a whole to collaborate on a single system.
2. Security - all enterprise softwares have security, it is inherent in supporting many concurrent users. In general, if you don't log into it, it's probably not an enterprise software. We can argue public web services and their classification as "enterprise", but we'll get to that later.
3. Scalable - all enterprise system are scalable, meaning they have the ability to increase or decrease with the demand on the system. There are IT standards that define "scalability" as well. You probably hear the words real application clusters (RAC) or GRID or High Performance Computing (HPC). IT wants to use clearly defined and market accepted scalability techniques, meaning if you design your own "scalability", your trying to make something enterprise that is not meant to be.
4. Compatible - Enterprise systems must be compatible with many IT standards in today environments. Operating systems, databases, hardware configurations, virtualization, transport protocols (TCP, IPv6, etc), web protocols, etc., etc. They must also pass some criteria of being "modern" in terms of support development languages and customization techniques (nobody buys COBALT or COM solutions anymore). So enterprise system have an architecture that supports deployment on any type of "server".
5. Standards - Enterprise software must be build on standards, not only IT standards, but in the geospatial market, ISO interoperability standards and OGC application profile standards. It is these standards that standardize the data into something "usable" by other systems (not a stovepipe) and enable any business system who want to consume GI with standard interpretable services and data without the requirement to deploy massive SDK's and middleware.
So lets collate our findings:
Enterprise Software is secure and collaborative software, scalable with IT standard technologies, compatible with IT standard technologies.
A good exercise is to look at your software and see if it "fits" into this definintion!
Here is a stab at "enterprise software" on wikipedia. I love wikipedia, but that reading is "wikidiculous". "Enterprise Software" is not defined by "solving" an enterprise (entire business level) problem, that would allow almost any software be enterprise. All business units need to "compress" files to make them smaller for distributing them in e-mail...does that make WinZip an "enterprise software"?
There are lots of search engine permutations that you can attempt to find information on "enterprise", "enterprise computing", "enterprise requirements", "what is enterprise"...all leading to a dead end of NO DEFINITION. Its strange that we can probably name 5 enterprise class softwares off the top of our head (I would say Oracle, SAP, E-Bay, Google, and of course, the Leica Image Manager). What "separates" these softwares from the non enterprise class?
...lets start with defining "properties" of enterprise software so we can come up with a "Websters-like" Dictionary definition.
1. Collaborative - all enterprise softwares are multi-user by design. The architecture must support many concurrent user connections and the ability to process each individual users requested as a single transactional unit. This multi user ability allows the users as a whole to collaborate on a single system.
2. Security - all enterprise softwares have security, it is inherent in supporting many concurrent users. In general, if you don't log into it, it's probably not an enterprise software. We can argue public web services and their classification as "enterprise", but we'll get to that later.
3. Scalable - all enterprise system are scalable, meaning they have the ability to increase or decrease with the demand on the system. There are IT standards that define "scalability" as well. You probably hear the words real application clusters (RAC) or GRID or High Performance Computing (HPC). IT wants to use clearly defined and market accepted scalability techniques, meaning if you design your own "scalability", your trying to make something enterprise that is not meant to be.
4. Compatible - Enterprise systems must be compatible with many IT standards in today environments. Operating systems, databases, hardware configurations, virtualization, transport protocols (TCP, IPv6, etc), web protocols, etc., etc. They must also pass some criteria of being "modern" in terms of support development languages and customization techniques (nobody buys COBALT or COM solutions anymore). So enterprise system have an architecture that supports deployment on any type of "server".
5. Standards - Enterprise software must be build on standards, not only IT standards, but in the geospatial market, ISO interoperability standards and OGC application profile standards. It is these standards that standardize the data into something "usable" by other systems (not a stovepipe) and enable any business system who want to consume GI with standard interpretable services and data without the requirement to deploy massive SDK's and middleware.
So lets collate our findings:
Enterprise Software is secure and collaborative software, scalable with IT standard technologies, compatible with IT standard technologies.
A good exercise is to look at your software and see if it "fits" into this definintion!
Subscribe to:
Posts (Atom)
