Cleaning Up

17 Sep 2009 16:42

Some of you, following Wikidot code on GitHub may see it's nicely split into templates, php, web and conf directories. But this is the first impression.

Maintaining Wikidot is a bit more complex, because, files uploaded to sites are located in web, side to side with some static Wikidot php and javascript files. Also for historical reasons, there are web/files--common and web/files--local directories, which maps to /common--* and /local--* URLs and in fact, the files--local is never served directly by the web server (need to check permissions first).

Also some time ago, we made static files versioned, so that we can apply more aggressive HTTP caching to them (reducing average page load time) and still be able to fix bugs on them without waiting a few days till the cache expire. In current model, URL to static file contains version hash, this may be for example: http://static.wikidot.com/v--b44e0ce810ee/common--javascript/WIKIDOT.js (notice the b44e0ce810ee). The whole static.wikidot.com is now hosted on Amazon's CloudFront, which means you get static Wikidot files from a server nearby your location and not always from USA.

This all become quite complicated, so we decided to make things really clear and simple in the source code. The primary rule: make the source code (updatable from git) separate from files uploaded by users and generated by Wikidot. Second rule: make files that are automatically generated during installation (not in the runtime) separate from persistent files (like the uploaded by users) and from source code.

And at the end there needs to be some place for logs and a place for temporary data (we need this to generate some random cool stuff, but after generating them, files are deleted).

So we end up with something like this:

  • WIKIDOT_ROOT
    • data/
      • avatars/ — user avatars
      • sites/ — site files (both generated thumbnails and uploaded files)
    • generated/
      • static/ — generated static files. This dir can be server directly by a fast non-PHP webserver for static.wikidot.com in case we don't want CloudFront anymore
    • tmp/ — temporary files including Smarty compiled versions of templates. Content of this dir can be safely removed
    • logs/ — Wikidot logs
    • everything else — comes from git and is unchangeable by application

Application needs write-access to data, tmp and logs. Generated dir needs write access to one installing or upgrading application.

Wikidot persistent data is now ONLY database and data/ directory, so it's easy to backup and restore the application (if you have enough time to make full backup of this).

There is still one exception to this nice schema which is php/db/base directory, which is autogenerated during installation from XML database definition files, but the cleaning is not over, I still work on this.

Nice thing about this work is that it does not need a lot of code changing, because directory paths are usually stored in one (max two) places in application, so this kind of totally reorganizing directory structure does not break things. As such, it is very very worth doing it. In the end we get clean internal structure of files and it's clear which files you can safely remove, which you can restore from git (and thus you can experiment a little on them — in case of crash, just re-download application), which are "state" of the Wikidot and where to look for logs.

This all is also very important, because we aim to make current Wikidot.com source open and as such we want it to be a nice code.

Comments: 0

File Systems On Solid State Drives Benchmark

13 Sep 2009 20:57

Recently I bought a solid state hard disk for my laptop. All have heard that SSDs are faster and better, and help booting your OS faster. While it's all true, you need to face a fact, that no mature file system available for Linux is ready (optimized) for SSDs.

During last 20 years, file system (and kernel-side logic like write schedulers and disk buffers) were made to optimize use of hard disks — magnetic hard disks. The disks are now quite fast when you read or write 1 GB file from them, but when you need to read 2000 small files that are located in different physical locations of the disk, their performance degrades.

Rotating disks

For the years, many developed systems (both software and hardware) to make as little disk seeks as possible. I've heard there are optimizations in kernel like: if you need to read a block that is 20 sectors after current position, don't seek, read the 19 useless sectors, and then read the meaningful one. I don't know if this is true and if yes, is this optimization of Linux kernel or some particular file system.

Solid State Drives

OK, so the file systems out there perform really well on rotating magnetic disk drives. So what about the solid state non-rotating disks. Are the previously talked optimizations good for them too? No. Solid state drives are not as fast as magnetic disks for sequential reads and writes, but they are much much better in random access to data. The seek time is approximately 0 (actually much less than 0.1 ms, when magnetic disks have the seek time about 5 ms).

SSD + File Systems?

On the other hand, there are quite a few new file systems that are meant to be run on SSD disks or at least are SSD-aware. I'm talking about NILFS2 and btrfs. Unfortunately neither of them is stable in the sense of on-disk data format. This means that partitions created with current version of NILFS or btrfs may not be readable by future versions of these file systems. Thus it's not too nice to have important data on them.

Looking for a benchmark

So this is time when I have my expensive SSD in my hand and face serious problem of choosing the right file system to keep my data secure and fast to access. I searched for some benchmarks to compare the results of different file systems, both the old XFS, ReiserFS, ext2/3, the new ext4 and SSD-optimized btrfs and NILFS2. The number of benchmarks of these filesystems on SSD drives I found is 0. So time to make my own benchmark.

My benchmark

I want to benchmark the following file systems:

  • ext2, ext3
  • ext4
  • xfs
  • reiserfs, reiser4
  • nilfs
  • btrfs
  • zfs (via fuse)

I will use my new OCZ Agility 120 GB SSD disk for this.

As this option is used even for magnetic disks, I will append noatime to mount options for every file system I check.

Also, I will try the following tweaks as suggested by random sites:

  • using noop scheduler for disk IO: echo noop > /sys/block/sdb/queue/scheduler
  • turning on and off write-back caching: hdparm -W1 /dev/sda, hdparm -W0 /dev/sda
  • discourage swapping (so that app data is kept in RAM and is not replaced with disk buffers, reading from SSD is damn fast anyway): sysctl -w vm.swappiness=1

For each setting, I'll make a test with bonnie++. I'll try to make nice graphs out of the data.

If you want me to test more settings or file systems or have some suggestion about the benchmarking tools, feel free to leave a comment.

UPDATE: I will also perform one more test: time of launching Firefox, Claws Mail and Pidgin from encfs-encrypted .mozilla, .purple and .claws-mail directories with different underlying file systems. This is very common task for me (they all start automatically after logging in).

Comments: 0

Problemy z Netią

04 Sep 2009 09:27

Dzisiaj rano ku mojemu zdziwieniu nie mogłem pobrać poczty z mojego serwera. Pomyślałem, że nie działa internet, ale działa. Druga myśl, serwer padł. O nie! Ale serwer działa (sprawdzone z serwera w firmie). Sprawdziłem jeszcze szybko inny serwer w naszej serwerowni i też nie działał. No to jasna sprawa, szybki tracepath i potencjalnie wadliwy router namierzony.

Dzwonię czym prędzej do Netii, aby zgłosić mój problem, ale wpierw muszę zaktualizować swoje dane (które nie zmieniły się od początku trwania umowy). Więc podaję swój numer komórkowy i e-mail i już, już prawie szczęśliwy, że mogę opowiedzieć na czym polega problem zaczynam, aby dowiedzieć się, że:

  • działa panu internet, a jakaś strona nie, to nie nasz problem
  • pewnie ma pan wirusy (a może bakterie?)
  • rozmawiam z osobą, która WIE co to jest PING, TRACEPATH i ROUTER, ale nie potrafi odpowiedzieć na prośbę:

Czy mógłbym prosić, aby powiedziała mi Pani do jakiego adresu IP rozwiązuje się nazwa hetzner.de

(Odpowiedzią na to pytanie było: ale Pan nie ma stałego IP i dlatego Pana nie widzę)

Poprosiłem, aby kobieta zapingowała adres, który mi nie działa i niby jej działa. No to może faktycznie problem u mnie jakiś. Zrestartuję swój router i zobaczymy.

Poprosiłem w międzyczasie Slafsa, który jeden z serwerów w firmie ma podpięty do internetu przez Netię, ażeby zapingował dla mnie hetzner.de i również nie dostał odpowiedzi, a tracepath zatrzymał się na tym samym hopie.

Zadzwoniłem zatem drugi raz na infolinię. Tym razem odebrał mężczyzna. O niebo wolę rozmawiać o takich rzeczach z przedstawicielami tej samej płci. Przedstawiłem mu problem przekazując jak najmniej szczegółów. Zapytał jaki komunikat otrzymuję gdy próbuję otworzyć tę stronę. Powiedziałem, że próbuję zapingować ten serwer (co działa z internetu TPSA) i nie dostaję odpowiedzi, a gdy uruchamiam tracepath, to pakiet zatrzymuje się na konkretnym routerze. Dodałem, że problem dotyczy również innych serwerów w tej serwerowni i usłyszałem klarowne i oczekiwane:

Rozumiem

To było mocne. Kwintesencja męskiej komunikacji w jednym słowie. Po chwili dodał, że sprawdzi i pochwili wrócił do telefonu i powiedział, że jest problem (!), że wystawi zgłoszenie i sprawdzą, czy jest to problem masowy. Hurra!

Będę mógł się podłączyć do jabberpl.org, żeby zalogować się do jabbera (jednego z kilku kont). Będę mógł sprawdzić pocztę nie korzystając z proxy SOCKS. Będę mógł zobaczyć stronę hetzner.de!

Może to nieuczciwe, ale uważam, że kobiety nie powinny rozmawiać z klientami takimi jak ja. Następnym razem jak odbierze kobieta odkładam słuchawkę i próbuję natrafić na faceta :).

Jeszcze naszła mnie refleksja, że dobrze byłoby widzieć aktualne problemy, które są znane pracownikom Netii i nad którymi pracują. Dobrym przykładem jest tutaj strona toruńskiego dostawcy internetu:

http://www.man.torun.pl/index.php?mod=tickets

Gdyby takie zestawienie było dostępne na stronach Netii, mógłbym śledzić na bieżąco rozwój wydarzeń. Scenariusz wydarzeń od rana mógłby wyglądać wtedy tak:

  • nie działa mi poczta
  • patrzę na stronach Netii, czy jest jakiś błąd
  • nie ma błędu, to sobie patrzę, czy to mój problem
  • nie jest to mój problem, więc dzwonię do Netii i zgłaszam
  • w Netii aktualizują tę stronę jeśli uznają, że to faktycznie jest ich problem
  • widzę, że to zrobili, czyli pracują nad tym (przynajmniej tak sobie myślę)
  • za jakiś czas jest aktualizacja, że wymienili router gdzieś tam i, że będzie działać za godzinę
  • za godzinę działa, problem na stronie przechodzi do archiwum

Tutaj pojawia się wniosek taki sam jak z naszego ostatniego zepsucia się Wikidota:

  • Ludzie nie są bardzo wkurzeni, że coś od czasu do czasu nie działa. Awarie się zdarzają
  • Ludzie są wkurzeni, jak nie wiedzą dlaczego coś nie działa
  • Ludzie są wkurzeni, gdy wiedzą, że jest awaria, a nikt nie chce im tego przyznać

Jak poradziliśmy sobie z tym w przypadku Wikidota? Gdy usługa nie działała, uruchomiliśmy statyczną stronę HTML z opisem awarii (dość szczegółowym) i postępów w jej usuwaniu. Po awarii napisaliśmy co zrobimy, gdy zdarzy się coś podobnego w przyszłości. Ludzie szczęśliwi, bo wiedzą, że potrafimy rozwiązywać poważne problemy, więdzą, że nawet jak będzie awaria, to ich dane są bezpieczne, więdzą, że Wikidot nie zniknie ot tak pewnego dnia. Trochę są smutni, że dzisiaj Wikidot nie działa, ale się cieszą, że będzie działał jutro.

I jeszcze mała ciekawostka:

IPv6 został opracowany w Bydgoszczy

Comments: 1

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License