A record of aiming to win ISUCON7 after a crushing defeat in the ISUCON6 finals

Published on October 1, 2016

A record of aiming to win ISUCON7 after a crushing defeat in the ISUCON6 finals

Under the team name "Anago," the three of us—@iwiwi, @zuisou, and @imos—took part in the ISUCON6 finals. In the end we managed to double our initial score, but we were plagued the whole time by a phenomenon where the score would not improve even though we had supposedly fixed the bottleneck, and it was a crushing defeat. Since we can't say anything definitive about the cause without the benchmark environment being provided, this article is a record of what we want to make use of next year. Next year, we would very much like to win.

Our approach to the finals

As with Passing the ISUCON6 qualifiers with C++, we used nineserver as-is. The final server configuration was the reference implementation with nginx and a C++ server layered on top. The other two members handled optimizations such as generating SVG in C++, while I concentrated on server tuning and parallelization. The results didn't improve much, but judging from what I heard at the social gathering, the approach itself didn't seem bad. Once the benchmark environment is made public, I'd like to investigate.

Things I want to improve by next year

  • Build an environment that delivers the best performance using Docker
    • Since the environment is different every ISUCON, I want to be able to prepare in advance by using Docker
    • nginx is hard to isolate because it reads hardcoded paths such as /var/run/nginx.pid, but I hope that gets improved
    • Simply using Docker can fail to deliver performance because kernel settings aren't inherited and so on, so I want to build it carefully while investigating properly
  • Stop building an environment that is completely isolated within the team, and instead create a mechanism that makes it easy to switch environments
    • In ISUCON6, we built environments within a single server that separated ports so team members wouldn't interfere with each other, but this took several hours to set up and was a big loss, so we'll stop doing this
    • It may affect collaborative work, but if we build an environment that switches easily, it should be sufficient
    • On the assumption that the backend server won't change drastically, it might be fine to have a configuration where the C++ part and the backend part switch independently
  • Prepare an external server in advance
  • Support streaming communication
    • This finals apparently had no major bottleneck here so we could ignore it, but since it could become a bottleneck next time, I'd like to support it
    • Streaming communication can't be profiled on the frontend, so we'll build a mechanism to record the time spent on the backend
  • Calling a different URL from within the C++ server
    • There was a request for this for profiling purposes
    • It might be good in the sense of parallelizing calls

Things I want to keep doing next year too

  • Fight with a custom C++ server
    • We learned in the qualifiers that implementing in C++ lets you come out on top among groups of people who did the same thing, so I want to keep doing it in future years
    • A format where you register handlers eliminates the need to edit the same file, so I want to keep using it
    • The mechanism of generating a specific string on the backend side and replacing it in C++ is convenient because it can be used without fully understanding the backend language, so I want to keep using it
  • Rewrite /etc/hosts first
    • We first pasted the settings into Google Docs and shared them with everyone
    • After that, we could access things like http://isucon1/, which felt like it saved us the trouble of looking up IP addresses

Other things that seem good to improve

  • Make it possible to call Go directly from C++
    • We haven't run into problems so far, but when complex processing is given (such as hashing we hadn't anticipated), I want to be able to handle it by copy-pasting without falling behind the Go crowd
  • Prepare libraries for Redis, PostgreSQL, SQLite, and so on
    • It was just by chance that these technologies weren't used, so I want to prepare for them in advance

Impressions of the event

The event's badges were incredibly well made and I was impressed. The choice of food at the social gathering—sushi, pizza, and KFC—was the kind of lineup that no matter who you ask is unquestionably delicious, and it was the best. As for the contest itself, at first there was a problem where we couldn't start up due to Azure's limits, but everything else proceeded smoothly and I'm very grateful. I'd love to win next year and set the problems the year after.