Небуферизованные запросы: снижаем потребление памяти WordPress
Снижение пикового потребления памяти благодаря в два раза заменой одной функции
Пиковое потребление оперативной памяти WordPress можно снизить приблизительно два раза и практически бесплатно. В чём секрет? В использовании правильных функций для работы с базой данных. Опытные программисты знают, что API MySQL предоставляет два варианта работы с результатом запроса: Последовательная обработка результата — при этом не происходит никакой буферизации результата, данные отдаются от сервера клиенту, минуя временные таблицы [...]
← Вернуться к полной версии записи «Небуферизованные запросы: снижаем потребление памяти WordPress»…
Автор: Wandering Soul; опубликовано в: WordPress; метки: MySQL, PHP, WordPress, база данных, оптимизацияСен
2010
Комментарии к статье «Небуферизованные запросы: снижаем потребление памяти WordPress» (28) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «Небуферизованные запросы: снижаем потребление памяти WordPress»
गते गते पारगते पारसंगते बोधि स्वाहा
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.


Отличный способ! Спасибо.
А разработчикам ВП не предлагал? Есть шанс, что они это реализуют?
Есть подозрение, что к версии 3.x они всё-таки перейдут на mysqli.
Вообще надо бы предложить, интересна их реакция.
Странно, но на моём сайте от такой замены ничего не поменялось – как “кушал” WP цельных 23 MB с копейками, так и продолжает…
См. ниже — потребление памяти WP останется таким же, потребление памяти MySQL уменьшится.
Странно, но у меня увеличилось время генерации странички, а память, если и увеличилась, то на ~0.5м.
А время генерации сильно изменилось?
А нет, даже потребление памяти не уменьшилось
Потребление памяти, которое показывает WordPress, останется тем же. Уменьшится потребление памяти со стороны MySQL, а WordPress всё равно прочитает весь результат в память.
а почему увеличилось время отклика страницы?
Сильно изменилось?
с ~0.4 do 0.5-0.6
Вообще интересно… Единственная причина, которая приходит на ум — на странице присутствует достаточное количество запросов на запись. С
mysql_unbuffered_query()таблица блокируется на запись до полного прочтения результатов. С другой стороны, блокировка будет возникать, когда читается уж слишком много данных — вряд ли такое должно происходить на блоге.Так что честно скажу, что точную причину не знаю.
Хотя на боевом сервере с 200+ сайтами это действительно помогло немного снизить нагрузку. Будем смотреть.
Решил испробовать, как новый метод, авось поможет, – не помог, к сожалению.
Было бы круто, если автор выложил оптимизированный вп, помнится когда-то обещал, но так и не выложил – это было реально действующее нововведение)
Мы с Владимиром пытались это сделать, но там было много проблем: во-первых, синхронизация с основной веткой WordPress (наши изменения в апстрим будет ох как непросто протолкнуть — уж слишком радикальные там изменения). Во-вторых, часть этой работы — это work for hire, что создаёт определённые юридические трудности. Ну и в-третьих, слишком много времени уходит на поддержку — мы занимаемся похожим делом для пары серьёзных клиентов, и времени, надо сказать, это отнимает очень немало.
А разве там не лицензия, которая дает право на свободное использование, бесплатное?
Раз вы делаете для клиента, нельзя ли потом в паблик? Это не буде считаться неправильным, это все равно что клиент заказал русифицикацию, но не знал, что есть уже бесплатное у Кактуса, к примеру. Плюс, вы бы неплохо себя продвинули за счет облегченного вп, стали бы важным ресурсом, как кактус, который уже забил. Или какие-то определенные условия для получения такого двига. Если вопрос стоит в деньгах, то и денег бы заработали с такого рода услуги.
В случае work for hire все права на (наш) код принадлежат заказчику. Ну и NDA мы тоже подписывали.
Владимир, как и Лекактус, забил на WordPress
Так что ему это сейчас в любом случае неинтересно. И насколько я знаю, он пишет свою CMS
вау!
чур, мы первые на тестирование новой CMS!!! )))
Ясно.
А цмс платная? Схожа с вп?
Подобного рода сделал и Макс, но самая большая и важная проблема – не такая популяризация, как у вп, соответственно, не такое кол. плагинов,тем и тп тп((
Бесплатная, пока делаю для себя (когда время есть). На WordPress не похожа.
[...] Прочитал в блоге Ars Longa, Vita Brevis о том, как можно снизить пиковое потребление [...]
mysql_unbuffered_query() имеет смысл использовать когда возвращаемых данных много, десятки и сотни тысяч. А в обычных условиях толку от такой замены не будет. Если надо снизить потребление памяти, то есть другие, более эффективные средства.
Смотря что выбирать и смотря сколько памяти. Для всяких VPS с 48 мегабайтами памяти будешь рад каждому килобайту.
Здесь еще немаловажен тот факт, как WordPress выбирает данные: например, если от записи требуется только ID и title, WP выберет все поля записи.
Ну или если к записи много комментариев, то даже несмотря на разбивку их на страницы, WordPress выберет все комментарии.
Вообще если по существу, то согласен: на нормальном сервере результат незаметен.