(33)
{あれ}{クリック単価}{希哲14年9月11日6歩}{頂帯}{北極6丁目}{希哲14年9月10日}{北極5丁目}{機が熟する}{新白熊作戦}{デライト宣伝}=}(70)

3日間短期集中生活最終日でもある北極5丁目最終日。

デライト宣伝方針デライト市場戦略に合わせ,宣伝活動ネット頂帯集約させることにした(2歩)。自分の生活律動を保つ上でも都合が良い。

実際やってみて,宣伝無闇時間を注ぎ込めばいいというものではない,と感じていた。これが昨日の日記にも書いた機運問題とも重なり,新白熊作戦長期化覚悟しはじめた。

開発上の目標とは異なり,世の中受け入れられるかどうかというのは努力以上に外的要因が大きい。どう頑張っても,十分に機が熟する前ならデライト成功しない。

幸いデライト収益化問題はほぼ集客一点絞り込むことが出来るようになった。

一時,広告クリック率クリック単価がともに低過ぎると感じていたが,最近は正常化している。デライトのような全く類をみないサービスでは,他所と同じように広告機能しない可能性もあると思っていたが,これは杞憂だったようだ。

また,8日出振るいから動作も非常に安定している。速度はまだ改良余地が大きいものの,サービス拡大に合わせて漸進的改良していける見通しは立っている。これも大きな安心材料になった。

あとはどれだけ利用者を呼び込めるかにかかっている。ここに来て,集客を今までより現実的に考えるようになった。効果の低い宣伝活動に時間をかけるくらいなら,その時間を他の業務にあてて資金を稼ぎ,長期戦に耐えうる体制を作るということも考えておくべきなのだろう。

短期決戦長期戦か,答え北極6丁目最終日20日の終わりまでに出すことにした。6丁目はどちらにでも転べるように準備しておく期間になる。

この軌道修正がこの時期に出来たと考えると,短期集中生活に早く入ってつくづく良かった。明日から生活律動を戻し,最後になるかもしれない1週間後の短期集中生活に備える。

2020-09-11 19:08
2020-09-11 01:02
{希哲14年10月25日の日記}{大規模流入}{面白そう}{希哲14年8月25日}{デライト営業}{『希哲日記』}{デライト}{感触}{改善}{最優先}=}(15)

デライト営業感触は相変わらず悪くないが,ほとんどの反応が「面白そう」止まりなのは気になっている。もう一押し必要なのだろう。

とはいえ,今のデライトでは大規模流入に耐えられないという確信が出来たため,もう少し時間稼ぎしておきたい。明日は速度改善最優先に取り組むことにした。

新規利用者登録自我登録)からの動線整備をさっさと済ませて宣伝攻勢したい,という気持ち直感が押し止めていたが,どうやらそれは正しかったようだ。

2020-08-26 00:53
2020-08-26 00:35
{半自動}{使用状況}{新括体採番法}{旧括体採番法}{8MB}{分割挿入}{希哲14年8月16日}{一括挿入}{仕様検討}{良い機会}=}(38)

知番予約分割挿入一括挿入分割)化を試みるが,速度問題改善しなかった(9歩)。

1回あたりおよそ8MB記憶使用量もあり,抜本的改良必要判断急遽新括体採番法」の方針をまとめ,知番予約による「旧括体採番法」から移行することにした。

旧括体採番法は単純に個々の知番使用状況記録していくというものであり,自分で使っている分には必要十分ではあったが,サービス拡大を考えると現実的ではない。また,知番拡張についても半自動でやっていたが,完全に自動化したい。

先送りにしてきた課題解決する良い機会なのだろう。

その他,自我設定徹案練り(2歩),マウスオーバー関連の仕様検討3歩)など。

2020-08-17 12:32
2020-08-17 12:11
{希哲14年8月16日の開発}{新括体採番法}{旧括体採番法}{新採番法}{generate_series()}{希哲14年8月16日の進捗時限}{希哲14年8月16日の進捗}{希哲14年8月16日}{手定め}{内部実装}=}(37)

知番新採番法について概ね方針が固まる。

括体採番法有用であるため踏襲し,内部実装のみ改良する。これまでの知番予約による方式を「旧括体採番法」とし,「新括体採番法」に移行する。

これまでのように個々の知番_dg_kno に保持するのではなく,知番節の有効範囲を保持するだけの定表を作り,外部結合により空き知番抽出する。

簡単な手定めを行い,問題のない速度が出ることを確認。この時,定表を作らず generate_series()動的生成することも出来るが,流石に数倍の速度差があり現実的ではない。

_dg_kno は構造をそのままにとなる知番節探索するために使う。

2020-08-17 00:33
=}
{希哲14年8月12日の開発}{ON 句}{ネステッドループ結合}{マージ結合}{20倍}{速くなる}{希哲14年8月12日の進捗時限}{希哲14年8月12日の進捗}{希哲14年8月12日}{一時凌ぎ}=}(35)

前後景一覧整備,装体書整理ページ付け自輪郭検索

途中で終了。

低速求頼については,ほぼ _dg_dg_oln結合部分で生じていることを突き止めた。

どうしても気になりあれこれ試行錯誤していると,WHERE 句 に書いていたフラグb_delb_bg_his)の条件count() 内に移した(OR NULL 付き)だけで,明らかに速くなることに気付いた。その差はおよそ20倍

いまいち理由把握しきれていないが,EXPLAIN ANALYZE では,WHERE 句にフラグ列を含めるとマージ結合になりかなり無駄な処理が入っていることが分かるが,count() に含めるとネステッドループ結合になり無駄なく索引が使われている。

WHERE 句のフラグに索引を張っても ON 句に移しても変化が無かった。

もう少ししっかり理解して最適化しなければならないが,良い一時凌ぎにはなるだろう。

ここで,昨年,_dg_olnn_fgn_bg を加えていたことを思い出した。すっかり忘れていた。これも活かせば,速度上の問題はほぼ解消しそうだ。

2020-08-12 23:07
2020-08-12 23:03
=}
{走る}{速度}=}(2)
{dg_kno_vac()}{希哲14年1月29日の進捗時限}{希哲14年1月29日の進捗}{希哲14年1月29日}{手定め}{進捗記録}{進捗時限記録}{進捗時限}{見通し}{改善}=}(14)

デライト最終調整KNEST 認証整理。

途中で終了。

dg_kno_vac() の簡単な 実装の手定めに成功。これまでかなり適当な PL/pgSQL 実装を使っていたため,見通し速度も比べ物にならないほど改善した。

2020-01-30 05:40
=}
{希哲13年12月28日のツイスト}{希哲13年12月28日}{デライト開発}{デライト}{ツイスト}{製品}{速度}=}(7)

デライト開発,信じられないような速度で進んでいるが……それだけに,私はいままでデライトという製品を何だと思っていたのか,という感じだな。

2019-12-28 18:40
=}
{進捗}{速度}=}(2)
{表示}{速度}=}(2)
1