PHPとPythonとRubyの連想配列のデータ構造が同時期に同じ方針で性能改善されてた話 - hnwの日記
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
php メモリ使用量測定メモ - kame's engineer note
Rails系の記事ばかりだったが、久々にphpでメモリの使用量を計測する機会があったので、やり方をメモっておく。 phpに割り当てられた現在のメモリ使用量を測定 memory_get_usage() を使用する。 http://php.net/manual/ja/function.memory-get-usage.php <?php echo "first:".memory_get_usage() / (1024 * 1024)."MB\n"; $arr = []; for($i=0;$i<10000;$i++) { $arr[] = $i; } echo "now:".memory_get_usage() / (1024 * 1024)."MB\n"; output first:0.21486663818359MB now:1.6373443603516MB phpに割り当てられたメモリ
PHPのcopy関数がファイルサイズ分のメモリを消費する件の対策 - hnwの日記
補足(2010/08/24 15:00)：rename関数について言えば、同一ファイルシステム上であればrenameシステムコールを利用するのでこの問題は起こりません。さらに蛇足ですが、ファイルシステムをまたがってrename関数を利用するとコピーしてから削除することになり、アトミック性を保証できないため、障害の原因にならないかどうかの検討が必要だと思います。 「AKIBA de: PHPのrename()関数はファイルシステム間で使うとメモリをバカ食いする」で指摘されている通り、PHPのcopy関数やファイルシステムをまたがってrename関数を使う場合に、PHPがファイルサイズと同じ大きさのメモリを消費してしまいます。環境によっては再現しないかもしれませんが、僕の手元のMacOSX 10.5+PHP5.3.3環境では再現しました。 <?php // 「dd if=/dev/urando
PHPで一時的なファイルポインタを扱う方法 - Qiita
選択肢 $fp = fopen('php://memory', 'r+b'); メモリ上に領域を確保する。メモリリークに注意。 $fp = fopen('php://temp', 'r+b'); メモリ上に領域を確保し、 2MB を超えたら自動削除される一時ファイルを作る。 $fp = fopen("php://temp/maxmemory:{$n}", 'r+b'); メモリ上に領域を確保し、$n バイトを超えたら自動削除される一時ファイルを作る。 $file = new SplTempFileObject($n); 上記の SplFileObject 版 (継承クラス) 。 引数は省略可能でデフォルトはもちろん 2MB (2 * 1024 * 1024 ) 。 0 にすることも可能。 OOP好きな人はこれでどうぞ。 $fp = tmpfile(); 自動削除される一時ファイルを作る。
さくらVPSで一日6万PVを処理するためにしたこと - 新卒インフラエンジニア２年目
さくらVPSで6万PV程度のサイトを運用することになったので、その際の記録を残しておきます。 さくらレンタルサーバ⇒さくらVPS さくらレンタルサーバで運用している時は、ちょくちょく503が発生しておりこれを解決するためにさくらVPSへの移行を行いました。 レンタルサーバの時は、ログ解析や監視ツールなどを導入していなかったので503の頻度やパターンは不明です。（安易な判断でVPSに移行したので、この点は反省です） 本来は原因を追及し、プログラムの改修やサーバ負荷の分散などをすべきですが時間の都合で省いてしまいました。 構成 運用するサイトはpukiwikiで構成されたサイトです。 pukiwikiは、PHPで書かれており大量のデータをRDBを利用せずに構築できる点が大きなメリットです。 今回は１サイトですが、複数のサイトを運用する可能性を考慮してVirtualHostも利用します。 さくら
PHP: パフォーマンスの考慮点 - Manual
パフォーマンスの考慮点 可能性があるルートを単純に収集すると、パフォーマンスにごくわずかな影響があると既に前述しました。 しかし、これは PHP 5.3 と PHP 5.2 を比較する場合です。 可能性があるルートを記録すると、PHP 5.2 のように全く記録しないものに比べてより遅いとはいえ、 PHP 5.3 のランタイムへの他の変更点により、この特有のパフォーマンス低下が一層際立つことが防止されています。 パフォーマンスが影響を受ける主な分野は2つあります。 1つ目は、減少したメモリ使用量で、 2つ目はガベージコレクション機構がそのメモリ・クリーンアップを実行する際の実行遅延です。 それら両方の問題を見てみましょう。 減少したメモリ使用量 まず第一に、ガベージコレクション機構を実装する理由は、 必要条件が満たされたらすぐに、循環参照された変数を整理してメモリ使用量を減らすことにあるので
Blog
明示的 意味 แพลตฟอร์มการเรียนรู้และพัฒนาทักษะด้วยเทคโนโลยี https://suin.io เป็นแพลตฟอร์มที่ให้คุณเรียนรู้และพัฒนาทักษะทางเทคโนโลยีอย่างสะดวกสบาย เรามุ่งมั่นในการให้ความรู้และประสบการณ์ที่มีคุณค่าในการพัฒนาตนเอง pascalcase
PHP: リファレンスカウントの原理 - Manual
リファレンスカウントの原理 PHP 変数は「zval」と呼ばれるコンテナに保管されます。 zval コンテナには、変数の型と値の他に、情報の追加ビットを2つ含みます。 1つ目は「is_ref」と呼ばれ、変数が「参照集合」の一部かどうかを示すブール値 です。 このビットによって、通常の変数と参照を区別する方法を PHP エンジンが知ります。 &演算子によって作成されるように、PHP ではユーザーランドで参照を使えるので、 zval コンテナもメモリー使用状況を最適化するための内部的なリファレンスカウント機構を 持ちます。 追加情報の2つ目は「refcount」と呼ばれ、この1つの zval コンテナをどれだけ多くの 変数名（シンボルとも呼ばれます）が指すかを含みます。 シンボルは全てシンボルテーブルに保管され、スコープごとにシンボルテーブルの 1つがあります。 関数やメソッドごとのスコープば
ホームページ作成の第一歩【PHP 覚書 メモリ不足？】
なんだかよくわからないが作ったものが動かない（この文章もいい加減不明過ぎ）。エラーを出力させてみると以下のような文言。 Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 11251014 bytes) in /home/piyo/html/private_html/cgi-bin/piyo.php on line 410 ちなみに該当行は「$comm = strip_tags($comm);」こんな処理。まぁエラーメッセージだけ見ればメモリ不足なんでたちまち以下の方法で回避。修正したのは「/etc/php.ini」。 ;;;;;;;;;;;;;;;;;;; ; Resource Limits ; ;;;;;;;;;;;;;;;;;;; max_execution_time = 30
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPのメモリの上限を変更する - Qiita
GitHub - calcinai/php-mmap: mmap for PHP based on a python subprocess
ふと備忘ログ» ブログアーカイブ » Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 500001 bytes) in