Как получить Google, как скорость с php?

Question

Я использую PHP с помощью Zend Framework и подключений к базе данных, похоже, занимает больше времени, чем 0,02 секунды, которые Google предпринимает для выполнения запроса. Сегодня я увидел видео, в котором говорится, что Google подключается к 1000 серверам для одного запроса. С задержкой я ожидал бы, что один сервер для каждого запроса будет более эффективным, чем наличие нескольких серверов в разных центрах обработки данных.

Как заставить PHP, MySQL и Zend Framework работать вместе и достигать одинаковых больших скоростей?

Является ли кеширование единственным способом? Как вы оптимизируете свой код, чтобы тратить меньше времени на «рендеринг».

Answer 1

Еще недавно Google решил поместить все в ОЗУ.

http://googlesystem.blogspot.com/2009/02/machines-search-results-google-query.html

Если вы никогда не должны запрашивать жесткий диск, ваши результаты будут значительно улучшить. Кэширование помогает, потому что вы не запрашиваете жесткий диск столько же, но вы все еще делаете, когда есть промаха в кеше (если вы не имеете в виду кэширование с помощью PHP, а это означает, что вы только компилируете программу PHP, когда источник был изменен).

Answer 2

Существует множество методов, которые Google использует для достижения объема пропускной способности, который он обеспечивает. MapReduce, Google File System, BigTable - это несколько из них.

Есть несколько очень хороших бесплатных & Open Source альтернативы этим, а именно Apache Hadoop, Apache HBase и Hypertable. Yahoo! использует и продвигает проекты Hadoop довольно много, и поэтому они довольно активно поддерживаются.

Answer 3

Это действительно зависит от того, что вы пытаетесь сделать, но вот несколько примеров:

• Проанализируйте свои запросы с объяснить. В среде вашего разработчика вы можете выводить свои запросы и время выполнения в нижней части страницы - уменьшать количество запросов и/или оптимизировать медленные.

• Используйте слой кеширования. Похоже, что Zend может быть включен memcache. Это потенциально может значительно ускорить ваше приложение, отправив запросы на сверхбыстрый уровень кеширования вместо db.

• Посмотрите время загрузки вашего фронтального интерфейса. Используйте надстройку Yahoo YSlow для Firebug. Ограничьте HTTP-запросы, установите заголовки будущего будущего для кеширования js, css и изображений. И т.д.

Вы можете получать молниеносные скорости в своем веб-приложении, возможно, не так быстро, как Google, если вы оптимизируете каждый уровень своего приложения. Время соединения с db, вероятно, не самая медленная часть вашего приложения.

Answer 4

Если это для поисковой системы, узким местом является база данных, в зависимости от ее размера.

Чтобы ускорить поиск по полному тексту на большом наборе, вы можете использовать Sphinx. Его можно настроить на одном или нескольких серверах. Тем не менее, вам придется адаптировать существующий код запроса, так как Sphinx работает как демон поиска (библиотеки доступны для большинства языков)

Answer 5

Согласно ссылке, предоставленной @Coltin, время ответа Google находится в области .2 секунды , не .02 секунд.Пока ваше приложение имеет эффективный дизайн, я считаю, что вы сможете добиться этого на многих платформах. Хотя я не знаю PHP, это бы меня лишило, если .2 секунды - проблема.

Answer 6

Memcached - рекомендуемое решение для оптимизации хранения/извлечения памяти в Linux.

Answer 7

Я использую PHP с Zend Framework и база данных подключается в одиночку, кажется, занять больше времени, чем 0,02 секунды Google требуется, чтобы сделать запрос.

Операции подключения к базе данных - это тяжеловес, независимо от того, кто вы: используйте пул соединений, чтобы вам не приходилось инициализировать ресурсы для каждого запроса.

Производительность - это архитектура, а не язык.

Answer 8

В Google имеется массивная высокораспределенная система, которая включает в себя множество проприетарных технологий (включая их собственное оборудование и операционные системы, файлы и базы данных).

Вопрос в том, как спрашивать: «Как я могу сделать свою машину грузовиком?» и по существу бессмысленно.

Answer 9

• Кэширование кода APC;
• Zend_Cache с базой данных APC или Memcache;
• CDN для статических файлов;

Answer 10

PHP-скрипты по умолчанию интерпретируются каждый раз, когда они вызываются сервером http, поэтому каждый вызов инициирует разбор сценариев и, возможно, компиляцию с помощью Zend Engine. Вы можете избавиться от этого узкого места, используя кеширование сценариев, например APC. Он хранит однажды скомпилированный PHP-скрипт в памяти/на диске и использует его для всех последующих запросов. Прирост часто бывает значительным, особенно в PHP-приложениях, созданных с использованием сложных фреймворков, таких как ZF.

Каждый запрос по умолчанию открывает соединение с базой данных, поэтому вы должны использовать какой-то пул соединений с базой данных или постоянные соединения (которые не всегда работают, в зависимости от конфигурации http server/php). Я никогда не пробовал, но, возможно, есть способ использовать memcache для хранения ручек подключения к базе данных.

Вы также можете использовать memcache для хранения данных сеанса, если они используются для каждого запроса. Их упорство не так важно, и memcache помогает сделать это очень быстро.

Фактическая проблема заключается в том, что PHP работает немного иначе, чем другие фреймворки, поскольку он работает в режиме SSI (на стороне сервера) - каждый запрос обрабатывается сервером http, и если для его выполнения требуется PHP-скрипт, его интерпретатор инициализируется, а скрипты загружаются, анализируются, компилируются и запускаются. Это можно сравнить с тем, чтобы попасть в машину, запустить двигатель и идти на 10 метров.

Другим способом является, скажем, способ приложения-сервера, в котором сам веб-приложение обрабатывает запросы в своем собственном цикле, всегда обмениваясь соединениями с базой данных и не инициализируя время выполнения снова и снова. Это решение дает гораздо более низкую задержку. С другой стороны, это можно сравнить с тем, что он уже находится в бегущей машине и использует его для управления теми же 10 метрами. ;)

Вышеупомянутые решения для кэширования/предварительной компиляции и объединения в пул наилучшим образом уменьшают накладные расходы init.PHP/MySQL по-прежнему остается решением на основе RDBMS, и есть веская причина, по которой BigTable - это просто крупная распределенная хэш-таблица с крупным распределением (немного упрощение, я знаю) - прочитал High Scalability.