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

[scripterz]

Здравствуйте.
Меня интересуют общие правила написания высоко-производимых веб систем, которым пользуются PRO веб программисты при написании своих скриптов дабы снизить нагрузку веб системы на сервер и добиться высокой производоимости, скорости.

 

[General Fizz]

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

 

[scripterz]

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

 

[General Fizz]

5. Для php - ищем профилеры вроде APD или встроенного в Zend Studio.
Для собственно линухподобных операционных систем - профиляторы вроде Для просмотра ссылки Войди или Зарегистрируйся.

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

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

8...

 

[kuka4a]

Мне кажется, эту тему в двух словах описать невозможно.
Вот ссылка на книгу "Building Scalable Web Sites"

Для просмотра ссылки Войди или Зарегистрируйся

Building Scalable Web Sites looks at a variety of techniques for creating sites that can keep users cheerful even when there are thousands or millions of them. Flickr.com developer, Cal Henderson, explains how to build sites so that large numbers of visitors can enjoy them. Henderson examines techniques that go beyond sheer speed, exploring how to coordinate developers, support international users, and integrate with other services from email to SOAP to RSS to the APIs exposed by many Ajax-based web applications.



This book uncovers the secrets that you need to know for back-end scaling, architecture and failover so your websites can handle countless requests. You'll learn how to take the "poor man's web technologies" - Linux, Apache, MySQL and PHP or other scripting languages - and scale them to compete with established "store bought" enterprise web technologies. Toward the end of the book, you'll discover techniques for keeping web applications running with event monitoring and long-term statistical tracking for capacity planning.




If you're about to build your first dynamic website, then Building Scalable Web Sites isn't for you. But if you're an advanced developer who's ready to realize the cost and performance benefits of a comprehensive approach to scalable applications, then let your fingers do the walking through this convenient guide.

 

[vario]

Scalable Web Sites и "веб системы с большой производимостью и низкой нагрузкой "

это не одно и то же

 

[PHP_Master]

Бредовый топик - нет общих правил, всё зависит от конкретной задачи.
А ТС хочет ответ в стиле книг "для чайников" или "освой бла-бла-бла за 24 часа".

 

[sartiii]

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

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

 

[venetu]

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

 

[Crazy108]

Добавлю немного:

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

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