Monday, April 30, 2012

Benchmarks: Some thoughts / Alguns pensamentos

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

Disclaimer
Although I have a perfectly clear disclaimer on the right side of the blog, I'd like to start this article by re-enforcing that disclaimer. Everything I'll write here are my own thoughts and in no way represent my employer view or position. It's probable also that the ideas presented here may go against some respectable people's ideas and some established opinions. I'd like to apologize if someone expects something different. Having said this, the ideas presented here are my real belief, based on my work experience, on my readings and many discussions with some very respectable people.

What is a database benchmark?
Database benchmarks are well defined stress tests and usually when we see references to them chances are that it's all about the TPC council published benchmarks. The TPC council is a non-profit organization whose members are database software vendors, hardware makers, and other IT related organizations. The purpose of the TPC (Transaction Processing Council) is to "define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry".
The TPC has defined several specs for benchmarks. The specs have designations like:

  • TPC-C
    OLTP benchmark
  • TPC-D
    Datawarehouse benchmark (deprecated)
  • TPC-H
    Datawarehouse benchmark (current)
  • TPC-DS
    Decision support benchmark (new)
  • TPC-E
    OLTP benchmark created to replace the TPC-C
The benchmark specs are very detailed and include everything that defines the tests. This include the database schema, the queries that are to be run, the several rules that specify what can and can't be used in terms of features, and also what must be used (like referential and check constraints etc.).
The benchmark reports include the measures taken, which are typically specified in number of transactions per time unit (the transactions are well defined in the specs). They also include the total system cost, which should include hardware and software costs including acquisition and support for a well defined period of time (3 years for example)
And these specs have evolved over time, due to several reasons:

  • New hardware and software features turned earlier specs useless (like materialized views which killed TPC-D)
  • New uses of software made some old specs look a bit outdated, meaning that new specs were created to better match the new reality
Personally I have no reason to assume that TPC was not created with good intentions. But for reasons that will be clarified along this article, I give no credit to the benchmarks. They only measure the will of a supplier to win, and how well it can twist the benchmark rules in order to achieve something worth publishing. Please note that although I have some commercial understanding of the market, I'm basically a technician. If you're talking to top management of big companies, they tend to don't understand any technical related argument, and they might, because of that, give some credit to the benchmarks published on TPC.org. But if you're talking to some technically aware person, I believe it's easy to dismantle a benchmark in around 10m (I'll try it for the top TPC-C published as an exercise).
Having said this, running a publishable benchmark represents an enormous technical and economic effort, and I must grant credit to the companies which do it.

The TPC-E mystery...
TCP-E benchmark specification was introduced because TPC-C had a lot of holes that made it unrealistic. You can easily find several opinions stating it's a better benchmark than it's predecessor.
But if you check the results you'll see that only one database vendor, Microsoft, has publish results for this. The mystery is why? Of course, MS supporters say it's because no one can beat them. No one else believes that. Most people who dedicate some time to study this believe that this is a leap frog game and it really depends on the investment. And if it's still done (or was) with TPC-C, a very mature specification, it should be even easier to do with a relatively new benchmark (the tricks are easier to discover and implement while the specs are still new). I've found several references on the Internet speaking about why no one entered the TPC-E "game", but none of them is conclusive (from my perspective). I can leave some references here for your own research:

You can decide for yourself. Personally I think the issue is related to what Mr. Jerry Keesee (IBM Informix database development director) explained in a public webcast (Chat with the labs) on 29 January 2009. More on that later.
But currently for OLTP, the most popular benchmark is TPC-C. TPC-E apparently is being pushed by hardware vendors (including IBM).

Benchmarks and Informix
Informix was a regular leader of benchmarks in the nineties. It used to partner with hardware vendors to achieve several top result in several categories.
The subject of benchmarks is very sensitive within the Informix community. Many people strongly believe that IBM should run official benchmarks using Informix. IBM never did it after acquiring Informix Software Inc. We may understand or not that position, but the reasons were clearly explained by Mr. Jerry Keesee, in a very clear answer to the question "How come IBM doesn't participate in public benchmarks of IDS? Like the TPC.org benchmarks?". The question was asked by a well known (and particularly critical of IBM) participant of the Informix forums at the end of a webcast in 29 January 2009. The reasons presented were:
  1. IBM has been doing TPC-C benchmarks with DB2 for a very long time. If we do one with Informix only two things can happen and they're both bad for IBM:
    1. Informix gets a better number, and the competition and analysts would crush us (IBM and DB2)
    2. Informix gets a worse number, and the competition and analysts would crush us (IBM and Informix)
  2. We could consider TPC-E, but currently there's only one vendor (MS) who published results on this kind of benchmark. Once we publish one (which would be better in absolute numbers or cost, since no one publishes a benchmark that doesn't show an improvement), we would have entered a very expensive race, because the vendor who is surpassed will probably reply and the leap frog game would start. Jerry prefers to invest on new features and product improvements which directly bring benefits to the customers.
You can't ask for something clearer than this. Meanwhile a benchmark on MDM (Meter Data Management) was done and published and Informix got a great result but this is not a standard. So it does not satisfy people who really want TPC results.

Very recently you may have noticed that the words "TPC-C" and "Informix" were floating around the social networks and some Informix related sites. That's because Eric Vercelletto decided to pick the TPC-C schema and specifications and run a non-oficial database stress test. While some people were jumping around in happiness others were criticizing him. My position is much more neutral, and I think most of the people talking about it never took the time to make a deep analysis of a TPC-C benchmark result. The opinions tend to be divided between something like "yeah!!! Informix finally has a TPC-C benchmark. Now we can show the performance Informix can achieve" and "Oh... The result is so low. He used the free version. It's useless". Really, if you want to speak about it, let's spend some time to look at some facts:
  • The benchmark run by Eric is not a true TPC-C benchmark. It's not official, it's not audited and yes, the number is very low if you compare it to other official published results (which by the way can't be done for legal and technical reasons)
  • Yes, Eric used the Innovator-C edition, which is a cut down version free of costs. It has limits and lacks some features that could help (only 2GB of RAM, no partitioning etc.)
  • Eric fought against technical problems with the clients sending the transactions. In fact he put the clients and the database on the same machine. Something you'll never see in a true benchmark
  • Eric used 4 hard disks. You can find a published result on TPC.org site with the same number of cores in the database server, that used 200 hard disks. Yes, you read correctly, two hundred hard disks (but for the top results the numbers are on the thousands)
  • The same  published benchmark used 10 cores for the clients and 4 cores for the database server. Compare that to the troubles Eric had with the client programs
  • Eric used 16GB of memory for both the database and the clients. The benchmark I mentioned above used 72GB just for the database server
  • Eric mention his system costs less than 900€. The system that run the above mentioned test was priced at more than $200000
  • Eric mentions he tried a client server configuration, but he could not reach more than 15-20% CPU use on the database server. This of course means he had great problems in the way the benchmark was being done (either not enough CPU power on the clients or other constraints like disk/memory on the DB server). In any case this would never get published if it was a true benchmark until the problems were fixed (in which case the numbers would rise dramatically)
So, given all this, are you assuming I don't appreciate Eric's work? Not so! Eric was a colleague at Informix Portugal around 1999 when I moved from a "4GL guy" onto an "engine guy" and he helped me on that. I know he's technically skilled and I appreciate his effort and his voluntarism to push this issue. What I'm trying to show is that the real TPC-C benchmarks belong to a completely different league. They use an unrealistic amount of hardware including CPUs, memory, disk, caching, Solid State Disks, and also an incredible human power. Every small detail is carefully analyzed and any bottleneck identified is studied to the limit. This sometimes brings real improvements to the products, but many times just creates a "smart scheme" to "fool" the benchmark rules. More on this later.
What Eric did is completely different and I never saw it being done: Take some commodity hardware like the one small customers may use, employ very little human effort, and try to make a stress test. Is it useful? Yes, but mostly for the person doing it, and eventually because it triggers others to do something similar or just talk about it. Is it comparable to the benchmarks you normally see referenced in press releases? No! You can't even start comparing it.
Another situation where I've seen people doing something similar is the Advanced Datatools promoted "fastest Informix DBA" challenge, that usually happens at the IIUG conferences. And it's interesting to see that Lester Knutsen will be showing this soon at Mac Tech. See it for yourself: http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share

Quick overview of the TPC-C top result
I mentioned earlier that I would go through the top TPC-C result published as of today in TPC.org. This benchmark was run by Oracle with version 11gR2 with RAC and partitioning. It achieved a very respectable result of over 30M tpmC (thirty millions of transactions per minute - type C -). The observations below are taken from the full benchmark disclosure report Let's see the facts:
  • [Page 6] The system cost was roughly $30M  (yes, thirty million dollars). Note that this price is not the price list. It includes a discount of $30M (50%).
  • [Page 4] It used 27 servers (oracle RAC nodes) for the database, each one with 4 Sparc processors. This means 1728 cores total (16 cores for each processor).
  • [Page 4] It used a central storage unit containing over 11000 24GB SSDs (Solid State Disks) and 720 2TB 7.2RPM SAS disks
  • [Page 4] Each one of the 27 nodes had 512GB of RAM, for a total of 13.5TB of RAM for the database servers side
  • [Appendix B] Most of the tables and indexes were partitioned in at least 27 pieces. Yes... 27, the same number of nodes. The why is explained below
  • [Appendix B] 27 UNDO tablespaces were created... yes 27 again.
  • [Page 30/TPC-C Spec] Clause 2.4.1.5 of the current TPC-C specs, define that any "New Order" (one of the five transactions) will refer to a "home warehouse" 99% of the times. So if you setup the clients properly, you split them for 27 RAC nodes. And 99% of the "New Order" transactions will use a "home warehouse". This will all be contained in one of the 27 table partitions. Meaning each database node will essentially work with one of the partitions. Now... The "New Order" transaction represented nearly 45% of all the transactions run in this test. The "Payment" transaction represented around 43%. And for this one, 85% of them used a "home warehouse".
  • What is the problem with RAC? The cache fusion... or in other words the piece of the system that guarantees data consistency across the nodes... It's a well known bottleneck, and Oracle usually says you don't have to change the application, but the fact is, if you don't, it will not scale. And TPC-C allows the system to be configured in a way that the various nodes act almost (99% of 45% and 85% of 43%) as if they were isolated nodes. So it scales... I bet you can imagine what Oracle would have to do to get a higher number...: Just add nodes and partitions... (change the application and keep the affinity)
  • [TPC-C Spec] From the other three transactions ("Stock level", "Order Status" and "Delivery") only one ("Delivery") includes data changes. The other two are read-only.
  • From the 3 later bullets you can understand how unrealistic this is, and the tricks used that take full advantage of it. But we still have one strong point about this benchmark: "Ok, I understand they dumped a ton of hardware and used allowed tricks to push the performance numbers... But what about the cost? It's cost per transaction is better than many previous benchmarks!". True! But once again, we must read everything very carefully. If you browse through several of these benchmarks (and this reflects reality) you'll notice that a very significant part of the cost is for software license and maintenance. The specs require the costs to be calculated for a three years period. And surely, all this hardware should raise the software costs, wouldn't it? Err... Yes, but no! Once again, let me explain... The TPC-C specs just require a calculation for 3 years. So what will a smart vendor do? Simply create a license that instead of perpetual is only for 3 years. As you can see here on the Oracle Price list, a processor license of enterprise version would cost you $47500. On the benchmark result [Page 5] you notice that the value is $23750. Then go back to the price list and notice the small letters on page 9. It states that for a 3 Year term license the cost is 50% of the perpetual license. So this cuts the software costs of the benchmark into 50% (without counting the global 50% discount on all prices). In a real situation it would mean a 75% discount on the software, but of course, after the 3 years period you'd need to uninstall the licenses or just buy new ones
  • Finally, support. The benchmarks mentions [Page 5] $62100 for Oracle Incident Server Support package per year. This is exactly 27 * $2300 which accordingly to the price list [Page 13] entitles you to web based support. I cannot find any item in the benchmark that would entitle you to upgrade your software as is normal when you pay S&S (Service and Support). Again, accordingly to the price list small lettered footer this would be 22% (per year) of the perpetual licenses.
So, I'm sure the above would not take more than 10m to explain to any customer. And in my perspective it shows the benchmark was twisted (in a fully legal and compliant manner of course) to increase the performance numbers and to decrease the cost. But neither the technical scenario nor the budget reflect a real customer scenario. This is why, in my opinion these benchmarks are worthless. And finally, if you ask me, I really prefer to have the money (and it's a lot) invested in the R&D of the product or in other marketing activities.

Having said this, I really think what Eric has done is an interesting exercise that may allow you to train your performance tunning skills. And I believe (no inside info here) that database vendors may use the schemas and queries to regularly test the software. It may allow them to notice positive or negative performance changes while they introduce new functionality and performance optimizations.
As for the published benchmarks? They exist solely for the purpose of getting headlines and press releases.

Versão Portuguesa:


Termo de responsabilidade
Apesar de ter um termo de (des)responsabilização perfeitamente claro no lado direito do blog, gostaria de começar este artigo por reforçar esses mesmos termos. Tudo o que escreverei aqui são as minhas próprias opiniões e ideias e de forma nenhuma refletem o ponto de vista ou posição da minha entidade patronal. É provável que algumas ideias apresentadas aqui vão contra as ideias de gente muito respeitável e algumas opiniões bem estabelecidas. Peço desculpa a quem esperasse algo diferente. Tendo dito isto, as ideias apresentadas são as minhas reais convicções, baseadas na minha experiência de trabalho, nas minhas leituras e em muitas discussões com pessoas que respeito muito.

O que é um benchmark de base de dados?
Os benchmarks de base de dados são testes de stress e habitualmente quando vemos referências a eles, é provável que se refiram aos benchmarks publicados pelo TPC council. O TPC Council é uma organização sem fins lucrativos cujos membros são fornecedores de bases de dados, fornecedores de hardware e outras organizações relacionadas com as tecnologias de informação (TI). O propósito do TPC (Transaction Processing Council) é "define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry". Numa tradução livre seria "definir benchmarks de bases de dados e processamento transacional e disseminar dados de permormance objetivos e verificáveis para o mercado". O TPC definiu várias especificações para os benchmarks. As especificações têm designações como:

  • TPC-C
    Benchmark     de OLTP
  • TPC-D
    Benchmark de Datawarehouse (descontinuado)
  • TPC-H
    Benchmark     de Datawarehouse (actual)
  • TPC-DS
    Benchmark de suporte à decisão (novo)
  • TPC-E
    Benchmark de OLTP criado para substituir o TPC-C
As especificações de um benchmark são detalhadas e incluem tudo o que define os testes. Isto incluí o modelo de dados, as queries que devem ser executadas, as várias regras que limitam o que pode e não pode ser usado em termos de funcionalidades e também o que tem de ser usado (como integridade referencial, check constraints etc.)
Os relatórios de benchmark incluem as medidas efetuadas, que são tipicamente especificadas em número de transacções por unidade de tempo (as transações são elas próprias definidas na especificação). Incluem também o custo total dos sistemas, contendo o custo do hardware e software, nomeadamente custo de aquisição e suporte por um período bem definido (3 anos por exemplo)
Estas especificações evoluíram ao longo do tempo por diversas razões:

  • Novas funcionalidades de hardware e software tornaram as especificações antigas inúteis (como as views materializadas que mataram o TPC-D)
  • Novas utilizações do software fazem com que as especificações antigas pareçam ultrapassadas, levando a novas especificações que pretendem refletir melhor a realidade
Pessoalmente não tenho razões para assumir que o TPC não tenha sido criado com boas intenções. Mas pelas razões que irei expôr ao longo deste artigo, não dou crédito aos benchmarks. Estes apenas medem a vontade de um fornecedor em vencer, e quão bem consegue distorcer as regras do benchmark com o objectivo de obter algo que valha a pena publicar. Note-se que apesar de ter algum entendimento comercial do mercado, sou basicamente um técnico. Se tiver uma conversa com a gestão de topo de uma grande empresa, tenderão a não entender qualquer argumento técnico, e poderão por causa disso dar algum crédito aos benchmarks publicados em tpc.org. Mas se estiver a falar com alguma pessoa minimamente técnica, acredito que é fácil "desmontar" um benchmark em cerca de 10m (tentarei fazê-lo como forma de exercício para o resultado TPC-C de topo)
Apesar disto, correr um benchmark publicável representa um enorme esforço técnico e económico, e nesse sentido tenho de dar crédito ás empresas que o fazem.

O mistério do TPC-E...
A especificação de benchmark TCP-E foi introduzida porque o TPC-C tinha uma série de falhas que o tornavam irrealista. É fácil encontrar opiniões que afirma que é um melhor benchmark que o anterior.
Mas se procurarmos os resultados vemos que apenas um vendedor de base de dados, a Microsoft, publicou resultados com esta especificação. O mistério é porquê?. Naturalmente os apoiantes da MS dizem que é porque ninguém os consegue bater. Mais ninguém acredita nisto. A maioria das pessoas que dedicaram algum tempo ao estudo destes benchmarks afirmam que se tornam numa "corrida de rãs" e que realmente dependem do investimento. E se ainda é feito (ou era) com o TPC-C, uma especificação muito madura, deveria ser ainda mais fácil de fazer com um benchmark relativamente novo (os truques são mais fáceis de descobrir e implementar enquanto os benchmarks são novos. Encontrei várias referências na Internet sobre o porquê de ainda ninguém ter entrado no "jogo" do TPC-E, mas nenhuma absolutamente conclusiva (na minha perspetiva). Posso deixar algumas referências para a sua própria pesquisa:

Pode decidir por si mesmo. Pessoalmente penso que o assunto está mais relacionado com o que o Sr. Jerry Keesee (director de desenvolvimento de IBM Informix) explicou num webcast público (Chat with the labs) em 29 de Janeiro de2009. Mais sobre isto adiante
Mas atualmente, para OLTP o benchmark mais popular é o TPC-C. Aparentemente o TPC-E está a ser publicado por vendedores de hardware (incluindo a IBM).

Benchmarks e Informix
A Informix era um líder regular dos benchmarks nos anos noventa. Costumava colaborar com parceiros de hardware para alcançar vários resultados de topo em diversas categorias.
O tema dos benchmarks é muito sensível dentro da comunidade internacional de Informix. Muitas pessoas acreditam fortemente que a IBM devia executar benchmarks oficiais com o Informix. A IBM nunca o fez desde que adquiriu a Informix Software Inc. em 2001. Podemos ou não entender essa postura, mas as razões foram claramente explicadas pelo Sr. Jerry Keesee, numa resposta muito clara à questão "Como é que a IBM não participa em benchmarks públicos de Informix? Como os benchmarks TPC.org?". A questão foi colocada por um participante muito conhecido (e particularmente critico da IBM) dos fóruns de Informix, no final de um webcast em 29 de Janeiro de 2009. As razões apresentadas foram:
  1. A IBM tem feito benchmarks TPC-C com o DB2 desde há longo tempo. Se fôr feito um com Informix apenas duas coisas podem acontecer, e são ambas más para a IBM:
    1. O Informix obtém números melhores e a concorrência e os analistas cairiam em cima da IBM (e do DB2)
    2. O Informix obtém números piores e a concorrência e os analistas cairiam em cima da IBM (e do Informix)
  2. Poder-se-ia considerar o TPC-E, mas atualmente apenas existem resultados publicados de um vendedor de bases de dados (MS). Após a hipotética publicação de resultados com Informix (que seria necessariamente melhor sob alguma perspetiva, dado que ninguém publica números piores) dava-se inicio a uma corrida muito cara, dado que o vendedor ultrapassado tentaria responder e a "corrida de rãs" começaria. E o Jerry prefere investir em novas funcionalidades e melhorias do produto que trazem benefícios diretos aos clientes
Não se pode pedir algo mais claro que isto. Entretanto um benchmark sobre MDM (Meter Data Management) foi executado e publicado, tendo o Informix obtido um excelente resultado. Mas não é considerado um benchmark standard. Portanto não satisfaz quem realmente anseia por um resultado TPC.

Muito recentemente pode ter notado qeu as palavras "TPC-C" e "Informix" andavam a ecoar pelas redes sociais e em alguns websites relacionados com Informix. Isto deveu-se ao Eric Vercelletto ter decidido pegar no modelo de dados TPC-C e nas especificações e ter executado um teste de stress de base de dados não oficial. Enquanto algumas pessoas davam saltos de contentamento outros criticavam-no. A minha posição é bastante mais neutral, e penso que a maioria das pessoas que falam sobre o assunto nunca tiraram um tempo para fazer uma análise profunda de um resultado de um  benchmark TPC-C. As opiniões tendiam a dividir-se entre algo como "Sim!!! Finalmente o Informix tem um benchmark TPC-C. Agora podemos mostrar a performance que o Informix pode atingir" e no extremo oposto "Ehc... O resultado é muito baixo. Ele usou a versão grátis. É inútil". Haja paciência. Se alguém quer falar sobre isto, então passemos algum tempo a ver alguns factos:
  • O benchmark executado pelo Eric não é um verdadeiro benchmark TPC-C. Não é oficial, não é auditado e sim, o número é baixo se o compararmos com os resultados oficiais publicados (o que por sinal não se pode fazer devido a questões legais e técnicas)
  • Sim, o Eric usou a edição Innovator-C, que é uma versão limitada e grátis. Tem limites e falta de funcionalidades que poderiam ajudar (apenas 2GB de RAM, não tem particionamento etc.)
  • O Eric lutou contra problemas técnicos com os clientes que enviam as transações. Na verdade ele colocou os clientes e a base de dados no mesmo sistema. Algo que nunca se vê num benchmark oficial
  • O Eric usou 4 discos rígidos. Podem encontrar-se benchmarks publicados no TPC.org, com o mesmo número de cores no servidor de base de dados usado pelo Eric, que usaram 200 discos rígidos. Sim, leu corretamente, duzentos discos rígidos (mas para os resultados de topo este número é em milhares)
  • O mesmo benchmark que referi acima usou 10 cores para os clientes e 4 cores para o servidor de base de dados. Compare-se isto com os problemas sentidos pelo Eric com os programas cliente
  • O Eric usou 16GB de memória para colocar a base de dados e os clientes. O benchmark referido usou 72GB apenas para a base de dados
  • O Eric menciona que o custo do sistema é menos de 900€. O sistema onde correu o benchmark referido custava mais de $200000
  • O Eric mencionou que tentou uma configuração cliente/servidor, mas não conseguiu atingir mais que 15-20% de utilização de CPU no servidor de base de dados. Isto evidencia grandes problemas na forma como o benchmark estava a ser feito (ou falta de poder de CPU nos clientes ou outros constrangimentos no lado da base de dados como disco ou memória). Em qualquer caso estes números nunca seriam publicados se fosse um verdadeiro benchmark até que os problemas fossem identificados e resolvidos (situação em que os números subiriam dramaticamente)
Dado tudo isto, se está a assumir que não aprecio o trabalho do Eric, está enganado. O Eric foi um colega na Informix Portugal por volta de 1999, altura em que passei de "um tipo do 4GL" para "um tipo do motor" e ele ajudou-me nisso. Sei que é tecnicamente muito bom e aprecio o esforço e voluntarismo ao pegar neste tema. O que estou a fazer é apenas tentar mostrar que os verdadeiros benchmarks TCP-C pertencem a uma categoria completamente diferente. Usam quantidades irreais de hardware incluindo CPUs, memória, disco, cache, solid state disks e também uma capacidade humana incrível. Todo e qualquer detalhe é cuidadosamente analisado e estudado até ao limite. Isto por vezes trás melhorias reais aos produtos, mas outras apenas cria "esquemas" para "enganar" as regras dos benchmarks. Mais sobre isto adiante.
O que o Eric fez é completamente diferente e nunca vi isso ser feito antes: Pegar em hardware banal, semelhante ao que qualquer pequeno cliente pode usar, empregar um mínimo de esforço humano e executar um teste de stress. É útil? Sim, mas principalmente para quem o faz, e eventualmente porque leva outros a fazer algo semelhante ou apenas falar sobre isso. É comparável com os benchmarks que normalmente vemos referenciados em notas de imprensa, blogs, e outros artigos na Internet? Não! Nem podemos começar a comparar.
Uma outra situação onde vi alguém fazer algo semelhante são os concursos fastest Informix DBA promovidos pela Advanced Datatools que decorrem normalmente durante as conferências do IIUG.
E é interessante verificar que o Lester Knutsen vai mostrar isto brevemente na Mac Tech. Veja por si mesmo: http://www.youtube.com/watch?v=ScDyRrsI3H4&feature=share




Revisão rápida do resultado TPC-C de topo
Mencionei antes que iria rever o resultado TPC-C de topo conforme publicação actual em TPC.org.
Este benchmark foi efetuado pela Oracle com a versão 11gR2 com RAC e particionamento. Alcançou um resultado muito respeitável de 30M tpmC (trinta milhões de transações por minuto - tipo C - ). As observações abaixo foram baseadas no relatório completo sobre o benchmark Vejamos os factos:
  • [Página 6] O sistema custa grosso modo $30M (sim, trinta milhões de dólares). Note-se que o preço não é o de tabela. Incluí um desconto de $30M (50%)
  • [Página 4] Usou 27 servidores (nós de RAC) para a base de dados, cada um com 4 processadores SPARC. Isto traduz-se num total de 1728 cores (16 cores por processador)
  • [Página 4] Usou uma unidade central de armazenamento com  mais de 11000 24GB SSDs (Solid State Disks) e 720 discos de 2TB 7.2RPM SAS
  • [Página 4] Cada um dos 27 nós de base de dados tinha 512GB de RAM, para um total de 13.5TB de RAM para o conjunto dos servidores de bases de dados
  • [Apendéce B] A maioria das tabelas e índices foi particionada em pelo menos 27 partições. Sim... 27, o mesmo número de nós. A razão é explicada adiante
  • [Apendíce B] Foram criados 27 UNDO tablespaces... sim, novamente 27
  • [Página  30/Especificação TPC-C] A cláusula 2.4.1.5 da especificação actual do TPC-C define que qualquer transacção "New Order" (uma das cinco transações) se deverá referir a um "home warehouse" em 99% das vezes que é executada. Assim, se configurar os clientes corretamente, divide-os pelos 27 nós de RAC. E 99% das transações "New Order" irão usar um "home warehouse", ou seja dados contidos em apenas uma das 27 partições das tabelas.. Mais... a transação "New Order" representa 45% de todas as transações de todo o teste. A transação "Payment" representa cerca de 43%. E para esta, 85% usam um "home warehouse".
  • Qual é o problema com o RAC? O cache fusion... ou por outras palavras o componente do sistema que garante a consistência da informação entre os nós... é um ponto de contenção reconhecido, e habitualmente a Oracle diz que não é necessário mudar a aplicação, mas o facto é que se não o fizermos não escala. E o TPC-C permite que o sistema seja configurado de uma forma que os vários nós atuam quase (99% em 45% das transações e 85% noutros 43%) como se fossem nós isolados. E logo escala muito melhor... Aposto que consegue imaginar o que a Oracle teria de fazer para obter um número maior... Adicionar nós e partições... (mudar a aplicação e manter a afinidade)
  • [Especificação TPC-C] Das restantes três transações ("Stock level", "Order Status" e "Delivery") apenas uma ("Delivery") incluí alteração de dados. As outras duas são apenas de leitura
  • Dos últimos 3 pontos pode entender-se o quão irrealista isto é e quais os truques para tirar proveito disso. Mas mesmo assim ainda resta um ponto muito forte relativamente a este benchmark: "Ok, compreendo que tenham despejado toneladas de hardware e usado todos os truques permitidos para empurrar os números da performance... Mas e sobre o custo? O custo por transação apresentado é menor que muitos benchmarks anteriores!". Verdade. Mas mais uma vez temos de ler tudo com muita atenção. Se folhear alguns destes benchmarks verificará que uma parte significativa dos custos é para o licenciamento e manutenção (e isto reflete a realidade). As especificações requerem que os custos sejam calculados para um período de três anos. E com certeza que todo este hardware deveria ter feito aumentar os custos de software, certo?! Err... Sim, mas não! Vamos à explicação. Se a especificação requer um custo a 3 anos, o que é que um fornecedor esperto fará? Basta criar uma licença que em vez de perpétua é apenas por 3 anos. Como pode ver na lista de preços da Oracle, uma licença de processador da edição Enterprise custaria $47500. No relatório do benchmark [Página 5] notará que o valor é $23750. Volte agora à lista de preços e repare nas letras pequenas na página 9. Informa que para uma licença com termo de 3 anos, o custo será 50% da licença perpétua. Assim isto corta o custo da base de dados em 50% (não incluindo o desconto global de 50%). Numa situação real isto significaria um desconto de 75% no software, mas claro que ao fim de 3 anos teria de desinstalar o produto ou simplesmente adquirir novamente as licenças
  • Finalmente, o suporte. O benchmark menciona [Página 5] $62100 para o pacote Oracle Incident Server Support, por ano. Isto é exatamente 27 * $2300, o que de acordo com a lista de preços [Página 13]  o habilita apenas a suporte via web. Não consigo encontrar em lado nenhum no benchmark algo que o habilitasse a efetuar upgrades de software como é normal quando se paga S&S (serviço e suporte). Novamente segundo as letras pequenas no rodapé da  lista de preços isto representaria mais 22% (por ano) da licença perpétua
Portanto, tenho a certeza que o exposto acima não demorará mais que 10m a explicar a um cliente. E na minha perspetiva mostra que os benchmarks são distorcidos (de forma completamente legal e dentro das regras claro) para aumentar os números de performance e reduzir os de custo. Mas nem o cenário técnico nem o de orçamento refletem um cenário real. É por isso que, na minha opinião, estes benchmarks são inúteis. Finalmente, se me perguntarem, realmente prefiro ver o dinheiro (e é muito) investido em I&D do produto ou em outras atividades de marketing.

Após tudo isto, penso sinceramente que o Eric fez um exercício interessante que poderá ajudar-nos a treinar as nossas capacidades de performance tunning. E acredito (sem informação privilegiada aqui) que os vendedores de bases de dados podem usar os modelos de dados e queries para testarem regularmente o seu software. Poderá ajudá-los a detetarem alterações positivas ou negativas na performance à medida que introduzem novas funcionalidades e otimizações.
Quanto aos benchmarks publicados? Existem apenas com o propósito de se conseguir cabeçalhos e notas de imprensa
Posted by at
Labels: , , , , , , , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)