Hatena::ブログ(Diary)

独りの超電波プログラマ このページをアンテナに追加 RSSフィード Twitter

2014-07-09

[] wiki-db新サイト設置メモ

自分用のメモ

  • アプリを別ディレクトリからコピーして編集
    • settings.py
    • manage.py
    • urls.py
    • uwsgi.ini
    • wsgi.py
  • nginxのポート転送を設定
  • db作成。create database (name) default character set utf-8;
  • app/(name)/manage.py syncdb
  • couchdbのテーブル作成

2014-05-09

[][] feedparser置き換え

2chnaviのサービスを運用するにあたって、リソースボトルネックは何かというと、実はCPUが一番きつい。HDDと違って足りなかったら遅くなるだけでよかったんだけど、流石に全てのフィードをとってパースするのに1時間以上かかるのは、1万以上のRSSがあるとはいえ遅すぎる。

http://d.hatena.ne.jp/kudzu/20120403/1333449336

にも書いたけど、原因はfeedparserの実装が糞遅いから。涙がでるほど遅い。

で、ちょっと調べてたらspeedparserというfeedparserとある程度互換があるfeedparserの実装があったので、試してみた。

https://github.com/jmoiron/speedparser

pypiでパッケージがあったので、pip install speedparserで入れた。

てきとうに2chnaviに登録してあるrssを100ほどdlしてみて、2つのパーサが生成するオブジェクトのフィールドを比べてみたところ、更新日時の解釈が若干違うけど、url、コンテンツ、タイトルなどは割と互換に見える(追記:コンテンツはfeedparserのほうがタグの正規化などを行ってしまうため、完全マッチはできなかった。SANITIZE_HTML=0でも同様)。100くらいしかまだ試してないから、もしかしたらエンコーディングとか色々と細かいところで気が利かないのかもしれんけど。

参考までに速度を一部載せておくと、

5.380 vs 172.251 index.html?xml.15

4.532 vs 1421.450 rss.1

2.985 vs 122.598 index.rdf.21

11.675 vs 910.587 index.html?xml.5

1.524 vs 131.796 index.rdf.6

3.764 vs 487.475 index.rdf.12

5.577 vs 593.087 index.rdf.36

3.477 vs 276.774 index.rdf.43

14.047 vs 7256.265 index.rdf.23

3.561 vs 90.582 index.html.1

4.213 vs 806.865 index.rdf.5

3.599 vs 542.688 index.rdf.34

1.437 vs 432.654 index.html

6.362 vs 1437.406 index.rdf.42

3.384 vs 272.167 index.html?xml.8

5.521 vs 1194.197 index.rdf.47

3.104 vs 143.062 index.rdf.28

3.376 vs 152.067 index.html?xml.12

4.367 vs 872.829 index.rdf.2

14.783 vs 9165.716 talk?feed=rss2

6.751 vs 980.692 index.rdf.19

1.984 vs 205.695 index.html?xml.18

3.122 vs 225.296 index.rdf.18

36.107 vs 19888.307 index.html.4

3.402 vs 316.764 index.rdf.54

2.829 vs 226.778 index.rdf.32

4.423 vs 1081.482 index.rdf.3

5.801 vs 1916.120 index.html.2

25.172 vs 6872.890 gamble?feed=rss2

4.735 vs 846.101 index.rdf.15

11.688 vs 6284.851 pc?feed=rss2

3.572 vs 374.356 index.rdf.7

3.788 vs 377.102 index.rdf.53

4.442 vs 795.737 index.rdf.4

27.751 vs 18444.048 manga?feed=rss2

3.590 vs 524.870 index.rdf.14

2.967 vs 221.017 index.rdf.48

3.441 vs 568.598 index.rdf.20

2.940 vs 303.711 index.rdf.13

8.368 vs 3125.123 index.html?feed=rss2

4.147 vs 139.066 index.html?xml.2

8.120 vs 1324.849 index.rdf.40

3.152 vs 133.390 index.rdf.52

3.258 vs 290.415 index.rdf.44

7.013 vs 96.820 rss

2.808 vs 181.106 index.rdf.22

2.967 vs 233.972 index.rdf.50

3.104 vs 421.921 index.rdf.39

6.247 vs 1839.871 index.rdf.29

2.168 vs 89.000 index.html?xml.19

2.829 vs 178.847 index.rdf.16

2.832 vs 161.458 index.rdf.51

2.636 vs 186.148 index.rdf.24

15.118 vs 7562.889 feed.3

3.090 vs 253.103 index.rdf.10

2.158 vs 205.923 index.html?xml.9

2.976 vs 229.955 index.rdf.1

3.398 vs 446.549 index.rdf.31

3.053 vs 276.134 index.rdf

1.991 vs 169.961 index.html?xml.3

11.469 vs 1167.462 index.html?xml.1

3.876 vs 626.648 index.rdf.30

5.847 vs 1982.844 index.html.3

2.025 vs 167.217 index.html?xml.17

3.242 vs 147.577 index.html?feed=rss2.2

16.571 vs 10932.801 sports?feed=rss2

2.047 vs 70.548 index.html?xml

3.254 vs 276.725 index.rdf.41

1.998 vs 158.414 index.html?xml.11

1.994 vs 210.396 index.html?xml.14

3.120 vs 258.864 index.html?feed=rss2.1

15.106 vs 8625.756 index.html?xml.7

4.855 vs 1182.983 feed.1

1.979 vs 160.850 index.html?xml.16

3.355 vs 428.056 index.rdf.35

11.931 vs 1417.789 feed.4

3.353 vs 307.679 index.rdf.45

3.776 vs 474.214 index.rdf.8

1.795 vs 50.013 index.html?xml.4

10.671 vs 6183.113 music?feed=rss2

3.641 vs 310.649 index.rdf.38

speedparserはclean_html=False、feedparserはfeedparser.PARSE_MICROFORMATS = 0を設定。

単位はmsecで、左がspeedparser、右がfeedparser。正確な数字をとるために何度も回したりとかはしてないけど、別にそんなことしなくても余裕でわかるくらい差が出てる。

ざっくりspeedparserが数十-数百倍くらい速い。feedparserがいかに遅いかよくわかると思う。

もう少しtestcase追加してunittest全部通したらdeployしてみようかと思う。

追記:

一時間以上かかってたクロールが3分もかからなくなった。

しかもその3分の大部分がいくつか返事が返ってこないフィードの待ち時間で、過半数はあっという間に終わってた。

f:id:kudzu:20140510034137p:image

右端のところが新しいparserを使ったところで、見ての通り、ピークが100%にいかなくなってる。互換性の問題で移植できなかった部分はfeedparserのままにしておいたせいで多分まだ高めになってる。その処理自体はioのほうがボトルネックになるから、気にしなくていいかな、と思って放置してる。

追記2:

f:id:kudzu:20140510035521p:image

べ、別に都合のいい部分だけ切り抜いたわけじゃないんだからね、ということでピークがすぎる部分も載せてみる。ピークが小さくなった上に、圧倒的に短くなってるのがよくわかると思う。

2014-04-29

[] pulse audio raop設定 / alsa設定

http://raspberrypi.stackexchange.com/questions/5508/redirect-audio-to-another-airplay-device

にしたがってできたはずなんだけど、rebootしたら動かなくなってた...。

まずはpulse audioからraopで音を飛ばすところを確認する。

$ pulseaudio --log-level=debug -vvvv

(snip)

D: [raop-sink] module-raop-sink.c: Thread starting up

D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Device added for object /org/pulseaudio/core1/source1

D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Source added for object /org/pulseaudio/core1/source1

D: [pulseaudio] module-device-restore.c: Could not set format on sink raop.ipanema.local

D: [pulseaudio] module-suspend-on-idle.c: Sink raop.ipanema.local becomes idle, timeout in 5 seconds.

D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Device added for object /org/pulseaudio/core1/sink1

D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Sink added for object /org/pulseaudio/core1/sink1

I: [pulseaudio] module.c: Loaded "module-raop-sink" (index: #21; argument: "server=[169.254.171.141]:5000 sink_name=raop.ipanema.local sink_properties='device.description="ipanema"'").

D: [pulseaudio] protocol-dbus.c: Interface org.PulseAudio.Core1.Module added for object /org/pulseaudio/core1/module21

I: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo idle for too long, suspending ...

D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo is 0x0004, suspending

I: [alsa-sink] alsa-sink.c: Device suspended...

D: [pulseaudio] core.c: Hmm, no streams around, trying to vacuum.

D: [pulseaudio] module-udev-detect.c: /dev/snd/controlC0 is accessible: yes

E: [pulseaudio] rtsp_client.c: Connection failed: Connection timed out

I: [pulseaudio] module-suspend-on-idle.c: Sink raop.ipanema.local idle for too long, suspending ...

D: [pulseaudio] sink.c: Suspend cause of sink raop.ipanema.local is 0x0004, suspending

もしやと思い

$ telnet 169.254.171.141 5000

Trying 169.254.171.141...

つながらず、macのほうでは

$ telnet 169.254.171.141 5000

Trying 169.254.171.141...

Connected to ipanema.local.

Escape character is '^]'.

試しにmacからping

$ ping ipanema.local

PING ipanema.local (192.168.0.38): 56 data bytes

64 bytes from 192.168.0.38: icmp_seq=0 ttl=255 time=5.395 ms

raspberry piからairmac expresstelnet

$ telnet 192.168.0.38 5000

Trying 192.168.0.38...

Connected to 192.168.0.38.

Escape character is '^]'.

avahiが胡散臭い。

pi@rpi ~ $ ping ipanema.local

PING ipanema.local (192.168.0.38) 56(84) bytes of data.

64 bytes from ipanema.local (192.168.0.38): icmp_req=1 ttl=255 time=0.761 ms

64 bytes from ipanema.local (192.168.0.38): icmp_req=2 ttl=255 time=0.801 ms

^C

      • ipanema.local ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.761/0.781/0.801/0.020 ms

pi@rpi ~ $ ping ipanema.local

PING ipanema.local (169.254.171.141) 56(84) bytes of data.

^C

      • ipanema.local ping statistics ---

7 packets transmitted, 0 received, 100% packet loss, time 6008ms

  • 立て続けでやると、二回目以降が何故かlink localのもので解決されるというのが問題らしい。
  • しょうがないからlink localのアドレスも割り振る。
    • force-bindはつけないと、普通のdefault routeあるせいか有効にならない。

pi@rpi ~ $ sudo avahi-autoipd eth0 --force-bind

Found user 'avahi-autoipd' (UID 111) and group 'avahi-autoipd' (GID 115).

Successfully called chroot().

Successfully dropped root privileges.

Starting with address 169.254.7.39

Callout BIND, address 169.254.7.39 on interface eth0

Received conflicting normal ARP packet.

Callout CONFLICT, address 169.254.7.39 on interface eth0

Trying address 169.254.204.240

Callout BIND, address 169.254.204.240 on interface eth0

Received conflicting normal ARP packet.

Callout CONFLICT, address 169.254.204.240 on interface eth0

Trying address 169.254.127.95

Callout BIND, address 169.254.127.95 on interface eth0

Received conflicting normal ARP packet.

Callout CONFLICT, address 169.254.127.95 on interface eth0

Trying address 169.254.99.123

Callout BIND, address 169.254.99.123 on interface eth0

Successfully claimed IP address 169.254.99.123

んで、ping

pi@rpi ~ $ ping ipanema.local

PING ipanema.local (192.168.0.38) 56(84) bytes of data.

64 bytes from ipanema.local (192.168.0.38): icmp_req=1 ttl=255 time=0.748 ms

64 bytes from ipanema.local (192.168.0.38): icmp_req=2 ttl=255 time=0.735 ms

^C

      • ipanema.local ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1000ms

rtt min/avg/max/mdev = 0.735/0.741/0.748/0.028 ms

pi@rpi ~ $ ping ipanema.local

PING ipanema.local (169.254.171.141) 56(84) bytes of data.

64 bytes from ipanema.local (169.254.171.141): icmp_req=1 ttl=255 time=1.47 ms

64 bytes from ipanema.local (169.254.171.141): icmp_req=2 ttl=255 time=0.703 ms

これやったけど、結局音出ない。

そもそもalsaで音出すのがまともに上手く行っていない。

http://raspberrypi.stackexchange.com/questions/639/how-to-get-pulseaudio-running


$ echo "play-file /usr/share/sounds/alsa/Front_Center.wav 0"|pacmd

Welcome to PulseAudio! Use "help" for usage information.

一応たまに音が出る。なんだこの糞は。

[] Raspberry PILCDをつなげる

http://d.hatena.ne.jp/kudzu/20140426/1398523133の続き

root@rpi:~# i2cdetect 0

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-0.

I will probe address range 0x03-0x77.

Continue? [Y/n] y

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

root@rpi:~# i2cdetect 1

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-1.

I will probe address range 0x03-0x77.

Continue? [Y/n] y

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3e --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

  • まさかの一発OKで、自分でも驚き
  • サンプルのハローワールドのshell script動かしてみた。

root@rpi:~# ./lcdhelloworld.sh

Error: Write failed

Error: Write failed

Error: Write failed

Error: Write failed

Error: Write failed

Error: Write failed

Error: Write failed

  • 原因はアドレスがi2cdetectで3eになっているので、これに合わせる必要がある。
    • コピペしたい人用に下に貼り付けとく。

#!/bin/sh

# LCD初期化

i2cset -y 1 0x3e 0 0x38 0x39 0x14 0x78 0x5f 0x6a i

sleep 0.3

i2cset -y 1 0x3e 0 0x0c 0x01 i

sleep 0.3

i2cset -y 1 0x3e 0 0x06 i

sleep 0.3

# a. 1行目の文字を出力 "ハロー"

i2cset -y 1 0x3e 0 0x80 b

i2cset -y 1 0x3e 0x40 0xCA 0xDB 0xB0 i

# b. 2行目の文字を出力 "ワールド"

i2cset -y 1 0x3e 0 0xc0 b

i2cset -y 1 0x3e 0x40 0xDC 0xB0 0xD9 0xC4 0xDE i

やたら文字が薄いのはそういうハードウェアなのか、なんか自分が失敗しているのかどちらか不明。