Общие правила построения веб систем с большой производимостью и низкой нагрузкой

Тема в разделе "PHP", создана пользователем scripterz, 26 ноя 2008.

Статус темы:
Закрыта.
Модераторы: latteo
  1. scripterz

    scripterz Создатель

    Регистр.:
    20 апр 2008
    Сообщения:
    19
    Симпатии:
    0
    Здравствуйте.
    Меня интересуют общие правила написания высоко-производимых веб систем, которым пользуются PRO веб программисты при написании своих скриптов дабы снизить нагрузку веб системы на сервер и добиться высокой производоимости, скорости.
     
  2. General Fizz

    General Fizz Боевой Генерал :)

    Регистр.:
    11 апр 2007
    Сообщения:
    753
    Симпатии:
    396
    1. Для начала прочитать книгу Шлосснейгла Профессиональное программирование на php.
    2. Заменить Апач на связку nginx+fastcgi.
    3. Стараться не использовать стандартные цмс.
    4. Обязательна система (выборочного) кэширования данных.
    5. Неоднократный тюнинг не только php-кода, но и самого сервера с использованием здравого смысла и специальных программ.
    6. (Тут слегка отсебятю спорное мнение :p ) По возможности не использовать реляционные базы, а хранящие данные типа ключ/значение вроде Berkeley DB.
    7...
     
    hostvik1 нравится это.
  3. scripterz

    scripterz Создатель

    Регистр.:
    20 апр 2008
    Сообщения:
    19
    Симпатии:
    0
    3. +
    4. +
    5. примеры программного обеспичение :bc:
    6. Я знаю, что если делаешь большой проект, то использовать такие базы не целесообразно, потому что в конце концов получится скрипт, который будет выполнятся намного дольше из-за того, что базы данных построены умнее по работе с файлами :nezn:. Тикие системы целесобразно брать, если Вы делаете счетчик, гостевую книгу, фидбек отдельно, но не систему.
     
  4. General Fizz

    General Fizz Боевой Генерал :)

    Регистр.:
    11 апр 2007
    Сообщения:
    753
    Симпатии:
    396
    5. Для php - ищем профилеры вроде APD или встроенного в Zend Studio.
    Для собственно линухподобных операционных систем - профиляторы вроде gprof.

    6. Из личного опыта - сайты на пхп с посещаемостью несколько десятков кб посетителей/сутки. Используются две базы Беркли с продуманной логикой связей (функции с префиксом dba_). Реляционные принципиально не включал. Хостинг выделенный 755 пень, все летает. Двиг самописный.

    7. Используем zend или ioncube для ускорения работы.

    8...
     
  5. kuka4a

    kuka4a Постоялец

    Регистр.:
    3 окт 2006
    Сообщения:
    105
    Симпатии:
    6
    Мне кажется, эту тему в двух словах описать невозможно.
    Вот ссылка на книгу "Building Scalable Web Sites"

    http://www.nulled.ws/showthread.php?t=89507

     
  6. vario

    vario Создатель

    Регистр.:
    14 янв 2008
    Сообщения:
    10
    Симпатии:
    0
    Scalable Web Sites и "веб системы с большой производимостью и низкой нагрузкой "

    это не одно и то же
     
  7. PHP_Master

    PHP_Master

    Регистр.:
    3 фев 2008
    Сообщения:
    2.647
    Симпатии:
    591
    Бредовый топик - нет общих правил, всё зависит от конкретной задачи.
    А ТС хочет ответ в стиле книг "для чайников" или "освой бла-бла-бла за 24 часа".
     
  8. sartiii

    sartiii Постоялец

    Регистр.:
    17 сен 2008
    Сообщения:
    105
    Симпатии:
    17
    Меньше вычислений, больше статики. В реляционных БД избыточность помогает снизить нагрузку.

    Вон гуглу проще новые сервера покупать, чем код оптимизировать =)
     
  9. venetu

    venetu

    Регистр.:
    28 мар 2007
    Сообщения:
    737
    Симпатии:
    263
    Оптимизация веба это (в порядке приоритета:(
    1. Обдумать индексы
    2. Избавиться от лишних запросов.
    3. Вынести в background долгие задачи.
    4. Вынести тормозные запросы в кеш.
    5. Обдумать, в чем протупили со структурой базы
    6. Еще раз вынести в кеш все что возможно.
    7. Разнести вебморду по разным серверам (почему-то обычно первыми не вытягивают именно вебсервера).
    8. Разнести СУБД по разным хостам (разбивка базы на куски или репликация).
     
  10. Crazy108

    Crazy108 Создатель

    Регистр.:
    6 сен 2008
    Сообщения:
    45
    Симпатии:
    7
    Добавлю немного:

    1) не использовать прямого удаления записей, и связки из записей в разных таблицах. вносим изменения в таблицах, поле isDeleted и удаляем такие записи по крону раз в сутки к примеру.
    2) при проектировании системы используем ООП и 1 обьект - 1 запись в таблице. Апдейтим только те которые изменили и только в конце файла, только после того как все возможные действия завершены. не забывает lock table, + блокирование определенных действий созданием lock файла и удалением после произведенных операций. Это позволит избежать разсинхронизацию данных при двух и более одновременных потоках
    3) все данные использующиеся в качестве справозных данных вынести в кеш с обновлением к примеру 1 раз в час
    4) какую ЦМС использовать не принципиально, но только если она умеет кешировать результаты сборки страниц с учетов GET параметров, а также НЕ кешировать части страниц, где могут собираться динамические части контента. (счетчики, разные коды баннеров, количество онлайн, "реальные данные из базы")
    4) структуру базы данных проектировать таким образом чтобы не обращая внимание на количество таблиц - упростить работу с отдельными данными в случае апдейтов. Чем меньше запись, тем быстрее происходитапдейт. Таким образом количество кешируемых данных можно увеличить в разы, а тем самым снять нагрузку (но только на БД а не на файловую системы если хранить кеши в файлах)

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