> я правильно понимаю, что затраты на разбор строки сериализованных данных несравнимы с затратами на распарсивание кода?
зависит от реализации одного и другого. я считаю, что однозначно это утверждать нельзя. всё-таки разбор пхп-кода — это основная задача интерпретатора и оптимизация скорости этого процесса есть одна из первостепенных задач разработчиков. чего нельзя сказать про десериализацию.
> похоже, тут дело в кешировании исполняемого кода системой и получается прирост в производительности если данные одни и те же
стоял (и стоит) голый интерпретатор, без оптимайзеров, без кешеров. не могу утверждать на 100%, код не читал, но мне кажется, что сам по себе интерпретатор не кеширует код между запросами.
зы: php 5.2.13 win32, apache 2.2, windows 2k3 32bit, 8 процессоров по 2 ядра, 16 гиг оперативки.
1 — в процессе интерпретации ;-)
2 — ещё раз, я не говорю про длину и всё такое. кроме проверки длины нужно РАЗОБРАТЬ строку и СФОРМИРОВАТЬ структуру.
3 — это был список категорий :-) он практически не менялся. память не закончилась, памяти было несколько гигов свободно. сильно загружался процессор.
1 — Ну таки код РНР нужно перегнать в Zend-структуру? Или нет? :)
2 — Вы считаете, что unserialize — это только проверить длину строки и разместить в памяти? А то, что из строки нужно получить массив с правильными типами каждого элемента? Скорее всего внутри РНР идёт посимвольная обработка строки.
3 — Значит, запустили ab :)
4 — Не используется до сих пор. Всё, что изменили — переехали с винды на генту и спрятали апач за джинкс, но всё это вряд ли критично для конкретно обсуждаемого куска кеша.
Чтобы десериализировать данные нужно:
1. вычитать их из хранилища (файл, база, етс.)
2. разместить их в памяти
3. распарсить их в пхп-структуру, проверив корректность
Чтобы сделать инклюд нужно:
1. вычитать код из хранилища
2. разместить его в памяти
3. выполнить его, проверив на корректность
По-вашему выходит так, что распарсить строку в пхп-структуру быстрее, чем сделать eval. Вполне возможно, что в идеальных условиях так и есть, но в реальности, я повторюсь, мой метод выиграл у unserialize'а по производительности с огромным опережением. Речь идёт о проекте с ~200k хитов в сутки. Без нагрузки unserialize справлялся отлично, но как только нагрузку дали страница стала генериться по полминуты. Заменил unserialize на include — вышло 200-400 мсек без каких-либо акселераторов.
ну может сферический unserialize в вакууме и обгоняет сферический include… в боевых условиях, когда данные — это не просто range(1, 2000), а многомерный массив и обращение к этим данным происходит очень часто include выигрывает (наверное, за счёт кеша фс). по крайней мере, когда в DLE был дефолтный кеш на serialize+unserialize страница под нагрузкой генерилась 20 секунд. когда я сделал var_export+include она стала генериться 400 мсек.
… и значительно шустрее unserialize'а. проверено на собственной шкуре. даже массивчика в 2К элементов достаточно, чтобы заставить тупить сайт, использующий unserialize. при тех же условиях include работает сильно быстрее.
Растянуться они не могут, и не такое с батей в запорожце ими крепили. Другое дело, что по гладкой трубе они могут отличненько соскользнуть вниз в один прекрасный момент… Да и неэстетично всё это. Вообще, открывая тему ожидал увидеть крепление с нуля, а тут готовый кронштейн используется. Фе!
код вообще фееричен чуть более, чем полностью… $HTTP_GET_VARS уже лет пят как deprecated, да и mysql_insert_id вкупе с auto_increment PRIMARY_KEY было бы логичнее использовать, чем вести параллельно какой-то искусственный идентификатор.
Может быть пост подкорректировали с того момента, как вы его прочитали, но я лично там увидел и прочитал Doctrine, а не Symfony :-) Так что написано вполне логично :-)
Из Zend Framework'а очень органично выдирается практически любой компонент и не менее органично втыкается в любой код/фреймворк, спасибо архитектуре ZF. Так что отправка почты через Zend_Mail — вполне себе здравая мысль. В туторе к тому же Symfony в версии 1.4, если не ошибаюсь, использовался Zend_Search_Lucene для организации поиска по сайту и PHPMailer для отправки почты. Почему нет? Или стандартные решения нужно применять исключительно целиком без изменений?
В части объёма памяти, занимаемой браузером… Ну кагбе, у хрома это число вполне себе статичное, а фокс жрёт память на каждую вкладку метров по 70 + каждое установленное расширение это число увеличивает + со временем разрастаются всяческие sqlite'ы… В общем, лично я перешёл с фокса на хром исключительно потому, что фокс стал жрать память по полгига и запускаться по две-три минуты. До этого по году пользовался оперой, фоксом, теперь вот хромым… И пока я им доволен.
Банк списывает 90 копеек как безвозвратный кредит и тем самым портит кредитную историю клиента. В будущем клиент не сможет получить кредит ни в одном банке из-за злосчастных 90 копеек только потому, что первый банк посчитал звонок с уведомлением для себя невыгодным. Клиент расскажет всем друзьям и знакомым, какой это ужасный банк, опубликует гневный пост в жж, на хабре и/или ещё где-то. В результате в банк не придут 10-20-100-200-1000 человек и банк потеряет уже реально много денег. Дешевле потратить 20 рублей, чтобы вернуть 90 копеек и сберечь репутацию.
зависит от реализации одного и другого. я считаю, что однозначно это утверждать нельзя. всё-таки разбор пхп-кода — это основная задача интерпретатора и оптимизация скорости этого процесса есть одна из первостепенных задач разработчиков. чего нельзя сказать про десериализацию.
> похоже, тут дело в кешировании исполняемого кода системой и получается прирост в производительности если данные одни и те же
стоял (и стоит) голый интерпретатор, без оптимайзеров, без кешеров. не могу утверждать на 100%, код не читал, но мне кажется, что сам по себе интерпретатор не кеширует код между запросами.
зы: php 5.2.13 win32, apache 2.2, windows 2k3 32bit, 8 процессоров по 2 ядра, 16 гиг оперативки.
2 — ещё раз, я не говорю про длину и всё такое. кроме проверки длины нужно РАЗОБРАТЬ строку и СФОРМИРОВАТЬ структуру.
3 — это был список категорий :-) он практически не менялся. память не закончилась, памяти было несколько гигов свободно. сильно загружался процессор.
2 — Вы считаете, что unserialize — это только проверить длину строки и разместить в памяти? А то, что из строки нужно получить массив с правильными типами каждого элемента? Скорее всего внутри РНР идёт посимвольная обработка строки.
3 — Значит, запустили ab :)
4 — Не используется до сих пор. Всё, что изменили — переехали с винды на генту и спрятали апач за джинкс, но всё это вряд ли критично для конкретно обсуждаемого куска кеша.
Чтобы десериализировать данные нужно:
1. вычитать их из хранилища (файл, база, етс.)
2. разместить их в памяти
3. распарсить их в пхп-структуру, проверив корректность
Чтобы сделать инклюд нужно:
1. вычитать код из хранилища
2. разместить его в памяти
3. выполнить его, проверив на корректность
По-вашему выходит так, что распарсить строку в пхп-структуру быстрее, чем сделать eval. Вполне возможно, что в идеальных условиях так и есть, но в реальности, я повторюсь, мой метод выиграл у unserialize'а по производительности с огромным опережением. Речь идёт о проекте с ~200k хитов в сутки. Без нагрузки unserialize справлялся отлично, но как только нагрузку дали страница стала генериться по полминуты. Заменил unserialize на include — вышло 200-400 мсек без каких-либо акселераторов.
pastebin.com/xgbL3NUs
function cache_store($data, $key) {
file_put_contents(«cache/».$key.".php", "
зы: посмотрел на википедии, там развёрнуто в цикл. рекурсивное решение считается правильным? ;)
похапе, 10 минут. не уверен, что без ошибок :) тяжело писать и не тестировать :)