私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】フレームワーク CakePHP 12ホール目【笑】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>153
いきなり長文で余計な情報いっぱいの質問しても、
普通は回答なんてこないよ。
要点を手短に、具体的に。
あなたの質問なら
>「なぜcakeを使うのか?」
この1文以外は余計な情報じゃないですか。
いきなり長文で余計な情報いっぱいの質問しても、
普通は回答なんてこないよ。
要点を手短に、具体的に。
あなたの質問なら
>「なぜcakeを使うのか?」
この1文以外は余計な情報じゃないですか。
個人的にはcakeのプロジェクトに関わるはめになっただけ
そうでなきゃPHPなんか使う気がせん
そうでなきゃPHPなんか使う気がせん
プログラマーのために
IT用語かな読み辞典を作ろうと思うけど
どうですか?
IT用語かな読み辞典を作ろうと思うけど
どうですか?
>>162
誤爆ですか?
誤爆ですか?
>>164
え、マジでデーモンのdだったのか…
え、マジでデーモンのdだったのか…
口頭ベースの仕様書なしアジャイル開発が主流になってきてるから
memcached
これ日本語で統一されてないと
時間ロスになるじゃん。
だから
プログラマーのためのIT用語かな辞典が欲しいのであります。
memcached
これ日本語で統一されてないと
時間ロスになるじゃん。
だから
プログラマーのためのIT用語かな辞典が欲しいのであります。
このフレームワークMySQLにクエリ投げすぎじゃね?
ページ表示すると、CakeSqlLogが84行とかあるんだけど。。。
あえて可視化されて、多く感じるだけで、
他のフレームワークや、普通のシステムもこれぐらい投げてるものなのかな?
ページ表示すると、CakeSqlLogが84行とかあるんだけど。。。
あえて可視化されて、多く感じるだけで、
他のフレームワークや、普通のシステムもこれぐらい投げてるものなのかな?
余計な処理が多いというのは俺も感じる。
2系でそういうの無くなればいいが、おそらく無くならないだろう・・・
2系でそういうの無くなればいいが、おそらく無くならないだろう・・・
SHOW FULL COLUMNS みたいのはデバッグ時だけだからそういうのは差し引いていいよ。
insertしたあとに勝手にlastinsertidしたりというのはあるな。
しかもその後自分でlastinsertidしようとすると、またクエリ投げるし。
キャッシュ効いてるから対したロスではないんだろうけども、気になる。
しかもその後自分でlastinsertidしようとすると、またクエリ投げるし。
キャッシュ効いてるから対したロスではないんだろうけども、気になる。
CakePHPで掲示板つくって運営してるけど、
さくらインターネットからプログラム見なおせゴルアとお叱りうけて、
同時接続数制限かかりました
さくらインターネットからプログラム見なおせゴルアとお叱りうけて、
同時接続数制限かかりました
>>172
レン鯖か?VPSにすればいいのに。
レン鯖か?VPSにすればいいのに。
>>172
何プランですか?
何プランですか?
>>172
ここに書いたということはcakePHPが原因だったの?
ここに書いたということはcakePHPが原因だったの?
単にリクエスト数が増えたのが原因ならプログラム見なおせっていう言い方はされないんじゃないかな。
掲示板でそんな重い処理をしてるとも思えないから、インデックスがあたってないとか
slow quelyが多すぎるってことなんじゃないだろうか。
掲示板でそんな重い処理をしてるとも思えないから、インデックスがあたってないとか
slow quelyが多すぎるってことなんじゃないだろうか。
>>177
いや、俺が実際、あんたと同じような状況で
さくらレン鯖→さくらVPSに乗り換えてるから。
鯖のパフォーマンスは全く違うよ。値段も月980円だし。
ま、スタンダードプランと比べたら高いけどw
いや、俺が実際、あんたと同じような状況で
さくらレン鯖→さくらVPSに乗り換えてるから。
鯖のパフォーマンスは全く違うよ。値段も月980円だし。
ま、スタンダードプランと比べたら高いけどw
>>178
インデックスあたってないな
インデックスあたってないな
一概にDBとは限らないしslowqueryくらいは潰してるだろうから
まっとうにxhprofなんかでプロファイリングするのが一番だよ。
まっとうにxhprofなんかでプロファイリングするのが一番だよ。
ビューキャッシュの考え方について質問です。
例えば野球の選手データのように、毎日内容が変わるものがあるとします。
新しいデータを入れたらキャッシュを削除して再キャッシュすると思うのですが、
選手データのような、種類が多くて大量データの場合もそう言う考え方なのでしょうか?
例えば野球の選手データのように、毎日内容が変わるものがあるとします。
新しいデータを入れたらキャッシュを削除して再キャッシュすると思うのですが、
選手データのような、種類が多くて大量データの場合もそう言う考え方なのでしょうか?
オイラ、野球ぜんぜん見てないから選手データというのが毎日変わるというのは知らなかったんだけどさ、アクセスされるたびに更新するもんじゃなくて、1日ごとに更新する、でいいんじゃね?
というか、そういう更新するとこって、最終更新日とかタイムスタンプついてるところもある気がする。
というか、そういう更新するとこって、最終更新日とかタイムスタンプついてるところもある気がする。
野球の選手データなら、試合をして結果が出たとき以外には変わらないだろうし、
試合があったらその都度、攻撃とか守備とかのデータを追加して、選手ページのキャッシュ更新すればいいんじゃね?
俺も野球見ないからこんな仕様でいいのか自信ないけど
試合があったらその都度、攻撃とか守備とかのデータを追加して、選手ページのキャッシュ更新すればいいんじゃね?
俺も野球見ないからこんな仕様でいいのか自信ないけど
野球の選手データはあくまで例題なんですが、
そういう頻繁に更新するキャッシュ管理はどうするのかな?と思いまして。
毎日、何百のデータを一括削除してまたキャッシュし直すって
動作的にどうなのかな?と。そう言う疑問があります。
そういう頻繁に更新するキャッシュ管理はどうするのかな?と思いまして。
毎日、何百のデータを一括削除してまたキャッシュし直すって
動作的にどうなのかな?と。そう言う疑問があります。
>毎日、何百のデータを一括削除してまたキャッシュし直すって
それはバッチ処理。そういうのをする場合もあるが、普通のwebアプリで普通にCakePHPのキャッシュというと、アクセスしたらキャッシュするだけであって、何日も更新されない(アクセス来ないからそのまま)データもあれば、頻繁にキャッシュ更新される場合だってあるよ。
そこらへんのバランスとかどの方法がいいか?とかは一概に言えなくて、あくまでその部分を作る奴のバランス感覚とかセンスの問題だな
それはバッチ処理。そういうのをする場合もあるが、普通のwebアプリで普通にCakePHPのキャッシュというと、アクセスしたらキャッシュするだけであって、何日も更新されない(アクセス来ないからそのまま)データもあれば、頻繁にキャッシュ更新される場合だってあるよ。
そこらへんのバランスとかどの方法がいいか?とかは一概に言えなくて、あくまでその部分を作る奴のバランス感覚とかセンスの問題だな
>CakePHPのキャッシュというと、アクセスしたらキャッシュするだけであって、
>何日も更新されない(アクセス来ないからそのまま)データもあれば、頻繁にキャッシュ更新される場合だってあるよ。
これで納得しました。キャッシュってそういうもんなんですね。
例えバッチ処理であれ、大量のファイルを削除→再キャッシュすれば
時間がかかるだろうから、どうするのかな?って疑問に思っていたんです。
誰もアクセスしないファイルはそのままですか。納得です。
>何日も更新されない(アクセス来ないからそのまま)データもあれば、頻繁にキャッシュ更新される場合だってあるよ。
これで納得しました。キャッシュってそういうもんなんですね。
例えバッチ処理であれ、大量のファイルを削除→再キャッシュすれば
時間がかかるだろうから、どうするのかな?って疑問に思っていたんです。
誰もアクセスしないファイルはそのままですか。納得です。
最近、CakePHPはじめた者です。
hasManyとか定義するとfindしたら強制的に関連テーブルひっぱってくるSQLが走りますよね。
パフォーマンス上げるためにunbindModelってするのが1つの方法だけど、
・hasManyの定義がたくさんあったら、1つ1つunbindModelするのもしんどい。
・そもそも何かのテーブルに1つhasMany追加したら、findしてる既存のコード全部に影響が出る。
ちょっとありえないかなと・・・
そこで自分のアプローチとしては、以下のようにしようかと思います。
・hasManyとかは一切定義しない
・bindModelTable1()みたいなfunction定義
・その中で動的にhasManyを定義
・findを呼ぶ前に関連テーブルをひっぱってきたいときだけ、bindModel*()を呼ぶ
これ以外に良い方法ありますかね。
hasManyとか定義するとfindしたら強制的に関連テーブルひっぱってくるSQLが走りますよね。
パフォーマンス上げるためにunbindModelってするのが1つの方法だけど、
・hasManyの定義がたくさんあったら、1つ1つunbindModelするのもしんどい。
・そもそも何かのテーブルに1つhasMany追加したら、findしてる既存のコード全部に影響が出る。
ちょっとありえないかなと・・・
そこで自分のアプローチとしては、以下のようにしようかと思います。
・hasManyとかは一切定義しない
・bindModelTable1()みたいなfunction定義
・その中で動的にhasManyを定義
・findを呼ぶ前に関連テーブルをひっぱってきたいときだけ、bindModel*()を呼ぶ
これ以外に良い方法ありますかね。
>>196
うーん。たとえば、
・Model1にhasManyが10個定義されている
・Model2はhasManyを何も定義しない
・両方共同じテーブルを扱う
としますよね。
そうすると、hasManyのうち1つだけとか2つだけとかしたい時に、やっぱり面倒かなって。
みんなどうしてるのかな。
必要なときに必要なものだけひっぱるのがいいとおもうのだけど。
Railsはfind(:all, :include => [reviews, users])
みたいに必要なときに必要なものをって設計になってますよね。
ちょっとCakeの設計は解せないです・・・
うーん。たとえば、
・Model1にhasManyが10個定義されている
・Model2はhasManyを何も定義しない
・両方共同じテーブルを扱う
としますよね。
そうすると、hasManyのうち1つだけとか2つだけとかしたい時に、やっぱり面倒かなって。
みんなどうしてるのかな。
必要なときに必要なものだけひっぱるのがいいとおもうのだけど。
Railsはfind(:all, :include => [reviews, users])
みたいに必要なときに必要なものをって設計になってますよね。
ちょっとCakeの設計は解せないです・・・
>・Model1にhasManyが10個定義されている
この時点で設計が間違ってる。
みんなどうしてるのかな → 設計を見直してる
この時点で設計が間違ってる。
みんなどうしてるのかな → 設計を見直してる
>>195
本質的にhasManyって、用途によって切り替えるものじゃないと思う。
モデルって普遍的なものだから、もしも本当に切り替えが必要なのだとすると、
そもそもそのモデルに定義しているリレーション自体が適当なのか?ということも検討しないと。
本質的にhasManyって、用途によって切り替えるものじゃないと思う。
モデルって普遍的なものだから、もしも本当に切り替えが必要なのだとすると、
そもそもそのモデルに定義しているリレーション自体が適当なのか?ということも検討しないと。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- 【PHP】フレームワーク CakePHP 17ホール目【v3α】 (955) - [92%] - 2016/11/15 20:45
- 【PHP】フレームワーク CakePHP 14ホール目【v2.1】 (1001) - [92%] - 2012/12/3 19:16
- 【PHP】フレームワーク CakePHP 19ホール目【v3.3】 (844) - [92%] - 2023/2/2 14:30
- 【PHP】フレームワーク CakePHP 16ホール目【v2.4】 (1001) - [92%] - 2014/3/3 3:00
- 【PHP】フレームワーク CakePHP 11ホール目【v1.3】 (1001) - [92%] - 2011/6/30 22:32
- 【PHP】フレームワーク CakePHP 15ホール目【v2.2】 (985) - [92%] - 2013/9/7 8:30
- 【PHP】フレームワーク CakePHP 17ホール目【v2.4】 (984) - [92%] - 2015/1/10 2:45
- 【PHP】フレームワーク CakePHP 10ホール目【v1.3】 (1001) - [92%] - 2011/2/13 8:32
- 【PHP】フレームワーク CakePHP 13ホール目【v2.0】 (995) - [92%] - 2012/4/23 21:16 ○
- 【PHP】フレームワーク CakePHP 8ホール目【1.3】 (1001) - [91%] - 2010/7/22 22:16
- 【PHP】フレームワーク CakePHP 9ホール目【v1.3】 (1001) - [90%] - 2010/11/1 2:53
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [87%] - 2008/6/19 7:19 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [87%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [87%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [87%] - 2010/3/18 1:18 ○
トップメニューへ / →のくす牧場書庫について