Высоко нагруженный проект на PHP?

Question

[Евгений Елчев]

Доброго времени суток. Подскажите, что нужно учесть, какие фишки добавить в проект, что бы он выдерживал большой поток посетителей или посоветуйте литературу на эту тему.

P.S.: Проект скорее всего будет реализован на Zend Framework.

Answer 1

[suregood]

• Как можно больше кэшируйте
• При обращении к странице должно быть минимальное количество запросов к базе, а лучше вообще без них
• Используйте оперативку по максимуму, в свое время перевод некоторых элементов в проекте с MySQL на memcache дал большой прирост
• Заранее продумайте архитектуру серверов и связь серверов между собой для большей масштабируемости
• Отказывайтесь от Apache в пользу связки Nginx+php-fpm

Comments

[ggempire]

Связка nginx+apache-mod_php работает быстрее за nginx+php-fpm процентов на 10-15. Плюс связки nginx+php-fpm разве что в простоте настройки.

[ajaxtelamonid]

«nginx+apache-mod_php работает быстрее»
А можно пруф?

[ggempire]

только что прогнал — ab -c 20 -n 1000 myportal/index.php
лучшие результаты
nginx+php-fpm: Time per request: 61.253 [ms] (mean)
apache+mod_php :Time per request: 59.177 [ms] (mean)

но это не критерий поскольку сервак нагружен
пруф здесь
dklab.ru/chicken/nablas/49.html
и здесь
dev.1c-bitrix.ru/community/blogs/howto/568.php

Answer 2

[rPman]

в догонку к вышесказанному:
1. если СЕО позволяет, постарайтесь побольше делать на стороне клиента (javascript templates/ajax/..) и поменьше на сервере

2. не экономьте на разработке кода-управления кластером (а для высконагруженных проектов кластер нужен хотя бы для надежности): скрипты обновления (а и в проекте необходимо учесть что его код и данные могут обновляться), резервирование и восстановление из резервной копии, управление кластером — добавление/удаление/настройка узлов, и т.п.
Просто при плохой организации высоконагруженные проекты глючат чаще :) потому что банально 'тестеров' больше.

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

4. оптимизация sql это круто, но очень часто nosql решения (+что то по сериализации) вполне себе заменяют sql (а уж по скорости безусловно побеждают), как вариант — комбинированные решения (но последнее порождает чуть больше проблем при обновлениях структуры и кода)
* memcached — это кстати тоже nosql, только не является хранилищем (не гарантирует что если данные сохранил, то их можно будет извлечь)
* вот в решениях хранения не стоит городить собственных велосипедов и не стоит изобретать кошмар на файлах. НО, например небольшие статичные (редкоизменяемые) куски БД гораздо эффективнее подгружать прямо в виде PHP массива (до размера сотен кб php код иннициализации переменных работает значительно быстрее любого БД-фреймворка, не говоря уж про накладные расходы на соединения с БД и т.п.)

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

Answer 3

[web4_0]

Насчёт литературы, поскольку БД, в большинстве случаев — слабое место, то я очень рекомендую книгу
MySQL. Оптимизация производительности, 2-е издание, от Петра Зайцева и др.

Comments

[Антон Коссов]

ага, а лучше сразу забыть про мускул и работать с PostgreSQL))

[pwlnw]

Там такого не написано.

Answer 4

[Вячеслав Плиско]

ты уж определись, хайлод или зенд фреймворк.
и главное не слушай тех, кто берётся советы давать при столь малых входных данных. хайлоды бывают разные и бутылочные места могут быть в разных местах.
кстати, разработчики хайлодов проводят семинары spb-borodin.livejournal.com/596.html, есть масса статей по теме, прочитай как можно больше, чтобы увидеть разницу и понять, что нужно именно вашему проекту.
а лучше делай сайт как обычно, если пойдёт, то найдешь сложные места и перепишешь. всё равно без опыта сразу правильную архитектуру спроектировать не получится.

Answer 5

[jimmi]

из дополнительного, использовать:
— eAccelerator (если всё же апача осталась)
— поставить mysql в связку мастер — мастер для маштабируемости, при этом запись запросы можно делать на любой из серверов, и несколького слейвов для чтения.(это уже более денежный вариант)

Answer 6

[odmin4eg]

держу пару хайлоалов, вижу всё со стороны админа.

Самая беда это имеено затык к БД в вде числа запросов. сегодня это mysql, и надо быть готовым если «выстрелит» перейти на что-то вроде посгреса.

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

Оперу легче наращивать чем проц.

Answer 7

[alexber220]

проекты сразу высоконагруженными не становятся. обычно всё реализуется в сжатые сроки, затем запускается проект, исправляются баги, нагрузка постепенно растёт, приходит осознание того, что сервак скоро начнёт задыхатся, определяется слабое место, оно оптимизируется, с каждым разом оптимизировать становится сложнее, то есть дороже чем покупка / апгрейд железа, агрейдим, покупаем. Желаю топикстартеру добиться высокой нагрузки его проекта.