Предлагаю в этом топике обсуждать принципиальные отличия написания кода для highload-проектов от обычных. Например: почему в обычном проекте мы пишем PHP: <?php for($i = 0; $i < 3; $i++) { $array[] = $i; } ?> а в highload PHP: <?php $array[0] = 0; $array[1] = 1; $array[2] = 2; ?> Полезные советы буду дописывать в сюда: 1. Совет от Kreker 2. Совет от 440hz
Для организации цикла расходуется 72 байта памяти. Причем это не зависит от количества элементов. Но вот время набивания массива через цикл будет поболее, чем ручной способ. PHP: <?php $start = memory_get_usage(); $start_t = microtime(true); $array[0] = 0; $array[1] = 1; $array[2] = 2; echo (microtime(true) - $start_t)."<br>"; // 3.3855438232422E-5 echo memory_get_usage() - $start - 192; // 320 ?> PHP: <?php $start = memory_get_usage(); $start_t = microtime(true); for ($i = 0; $i < 3; $i++) $array[] = $i; echo (microtime(true) - $start_t)."<br>"; // 4.1961669921875E-5 echo memory_get_usage() - $start - 192; // 320 ?> Если количество элементов массива увеличить до 10 000, то разница в используемой памяти между первым и вторым примером будет равна 72 байта, как и в случае с тремя элементами.
По поводу $ar[$i] = $i и $ar[] = $i: 1. Памяти они используют одинаковое количество 2. А вот время выполнения разное: Прогоняем через командную строку: PHP: <?php $times = array(); for ($x = 1; $x <= 10000; $x++) { $start_t = microtime(true); for ($i = 0; $i < 3; $i++) $array[$i] = $i; $times[] = microtime(true) - $start_t; } echo array_sum($times) / 10000; //9.2637538909912E-6 ?> PHP: <?php $times = array(); for ($x = 1; $x <= 10000; $x++) { $start_t = microtime(true); for ($i = 0; $i < 3; $i++) $array[] = $i; $times[] = microtime(true) - $start_t; } echo array_sum($times) / 10000; //1.0567402839661E-5 ?> Как видно, разница в ~1.3037708099365E-6 в пользу $ar[$i] = $i
Почему в хайлоаде мы юзаем классы, а иногда вообще абстрогируем код до модулей, если издержки на это гораздо выше, чем у циклов?
При модульности проекта, его гораздо легче дополнять новым функционалом. Народ, кто работал с highload проектами, поделитесь ВАШИМ опытом оптимизации.
ИМХО узкие места в хайлоад не код, а базы данных и архитектура хранения информации. тяжелый SQL при не грамотном проектировании БД убъет все на корню сразу и надолго. ==== прежде всего в хайлоад я занимаюсь избыточной информацией. к примеру нужна статистика по дням и часам. для этого есть как минимум 2 таблицы в которых статистика уже посчитана с учетом дней и часов. показ статистики происходит из разных таблиц. во вторых все обсчеты информации делаются offline, т.е. сначала инфа сбрасывается в буфера а затем по крону обсчитывается. кластерность. php код и сама система не зависит на какой ноде она выполняется. при возрастании нагрузки просто дотыкаются железяки. причем обычные желехяки а не какие-там бренды за кучу бабок. отказоустойчивость. при выпадении любой ноды система продолжает работать без потери работоспособности. кеширование. большинство инфы может иметь задержку при обновлении. например я все запросы на выборки к SQL прогоняю через memcache на 5 минут, сокращая время выборок и вообще нагрузку на БД. собственно масштабируемость архитектуры проекта позволяет наращивать мощности обычными железяками, практически не модифицируя код.
у меня один пока хайлоад. продажа трафика из расчета 10лям хитов в сутки с возмо;ностью масштабирования. рабюотает кластер на 4 нодах. балансировщих nginx. mysql-cluster. все входящие данные сбрасываются в таблицу. далее ноды помечают свои записи. далее их обрабатывают, раскидывают по нужным таблицам. обработанные записи спервер статистики выбирает к себе и обрабатывает уже более точно и подробно. далее обработанные записи/данные удаляются совсем. помечают простым UPDATE clicks SET node = {$nodenum} и потом работабт уже с теми, где node = {$nodenum}
440Hz ок, спасибо. Народ, есть ли еще какие-нибудь мысли по оптимизации для хайлоад? Ок. Предлагаю на рассмотрение хайлоад систему обработки заявок. Исходные данные: посещаемость - 10млн хитов в сутки. каждую минуту добавляют 1000 заявок. По крону каждые 60 мин бегает скрипт, который смотрит необработанные заявки и отправляет уведомление. Предлагаю обсудить структуру БД. Есть соображения? ПС: это не относится к тому топику, который я создавал по поводу подобной системы. Та система готова и работает в режиме бета-тестирования.
если имеется ввиду мускульных - допустим 4 upd: а какую бы ты предложил архитектуру железа для такой системы? у тебя то опыта побольше в этом.
Что заявка не обработана. ЗЫ.: по мне так не принципиально, какого рода уведомление отправляется, ИМХО должно настраиваться.
а поточнее распиши? что за заявка? какие сервисы еще будут? выборки, просмотры? будет ли почта (уведомления)? вообще чем больше распишешь чем точнее поучится спрогнозировать поведение системы и ее архитектуру. в общем пиши... будем думать. думаю всем будет интересно.
Давайте попробую. Возьмем в качестве такой системы - систему управления проектами. Есть проекты, есть задачи. Задачи системы: предоставление удобного сервиса по управлению проектами. Пользователи системы: Project Manager (ПМ) Разработчики U1, U2 ... Un ПМ общается с заказчиком, обдумывает его требования к проекту и вносит его в систему. Разбивает проект на задачи, и назначает их на исполнение разработчикам со сроками (дата постановки, дата завершения). Разработчик может посмотреть свои задачи и установить им статус (выполнена, не выполнена). Чтобы было поинтереснее, по всем проектам, задачам ведется статистика (процент выполнения той или иной задачи, (не )выполненные проекты, (не )выполненные задачи), статистика по разработчикам (сколько задач поставлено, сколько (не )выполнено). По крону каждые 60мин бегает скрипт и делает следующее: если задача разработчиком просрочена, ПМ приходит уведомление, что такой-то не выполнил то-то. Eсть внутренняя почта. Т.е. каждый пользователь системы может отправить сообщение другому пользователю. Если маловато, то можно придумать еще что-нибудь, чтобы уж точно был хайлоад.
На рождение ребенка требуется 9 месяцев, вне зависимости от того, сколько женщин к этому привлечено. На каком основании ПМ будет считать время на задачу, если задача требует больше пары дней? на каком основании будет считаться процент?
если в компании даже 2000 программистов все равно это не highload. Давайте лучше возьмем другой highload пример типа соцсети vkontakte.ru - вот это реальный highload....Даже пусть крон рас в 60 мин скрипт обрабатывает например новости в какойто группе людей проверяя всех кто зареген в этой группе и отправляет им сообщения о новом сообщении в группе в которой они состоят, групп 10 000 000 а пользователй 40 000 000... Вот так например.
Имеется ввиду, что эта система сдается в аренду многим компаниям. Весь сервис крутится на сервере. Т.е. Один сервис, много компаний, много пользователей, много проектов и много заявок...и очень много статистики.