Алексей Шеин
41 сообщение
#17 лет назад
Здравствуйте, уважаемые коллеги!
Часто вижу проекты с требованием "умение разработки сайтов с большой нагрузкой/посещаемостью". В связи с этим хочу спросить: в чем специфика таких проектов? Какие технологии, или, к примеру, особенности архитектуры приложения, мне, как программисту, нужно будет учесть? Какими принципами руководствуетесь именно Вы? Пинки в сторону документации приветствуются
Раду М.
159 сообщений
#17 лет назад
Зависит от платформы на которой будет крутится сайт. Самые распростроненные это ASP.NET и PHP (остальные встречаются крайне редко). Соответсвенно под каждую платформу свои методы.

Но мне кажется что это стало стандартным требованием заказчиков, типа знания албанского языка приветсвуется. Никто реально не будет докапываться до разработки сайтов под большой нагрузкой, да и эффективность лечения нагрузки решается либо апгрэйдом оборудования либо новым тарифным планом на хостинге, это дешевле, быстрей и самое главное эффективней.
Алексей Шеин
41 сообщение
#17 лет назад
Интересует PHP+MySQL.
Раду М.
159 сообщений
#17 лет назад
Копни в сторону Smarty или FuseBox. Вообще в плане PHP говорить про оптимизацию работы скриптов и нагрузкоемкость много не приходится. Изначально платформа не задумывалась под такие вещи. Нагрузка на ресурсы зависит почти линейно от количества запросов и что-либо сделать затруднительно. Так что методы и технологии оптимизации здесь весьма стандартные и просты в реализации, главное правильно писать код и знать как он будет обрабатываться парсером.

Всякие там "особенности архитектуры приложения" и прочие крылатые фразы пришедшие из области коммерческих платформ аля ColdFusion, Java и ASP.NET здесь уместны разве что в плане "не отстать от жизни" и обогатить тему новыми терминами. PHP как платформа уже не молодая, новых концепций в плане "особенностей архитектуры приложения" довольно мало. Это и плохо и хорошо одновременно, с одной стороны просто и надежно, многие моменты проверенно долгим сроком и многочисленным количеством сайтов. С другой стороны мир быстро меняется, а динозавры вымирают. В этом плане Smarty и FuseBox предлагают нечто вроде новых "особенностей архитектуры приложения", последний кстати пришел из мира ColdFusion, а первый больше смахивает на "наш ответ микрософту".
Андрей Л.
457 сообщений
#17 лет назад
Chevron, +1

+
Правильно составит структуру БД.
Раду М.
159 сообщений
#17 лет назад
Извиняюсь, немного дополнил и обобшил текст.
Андрей Халецкий
3563 сообщения
#17 лет назад
Самое важное, как правило, не PHP а SQL запросы (структура базы, использование возможности mySQL), именно они тормозят сайты.
Miksir D.
10 сообщений
#17 лет назад
Понимать, что делает твой код. Это основы любого программиста, но поскольку большинство PHP-истов - самоучки, то часто тут существенные недоработки. Я говорю о банальных вещах, таких как вынос того, что можно вынести из циклов и т.д. и т.п. Основы понимания работы с памятью бы тоже очень важны, ибо об освобождении переменных мало кто думает.
Знание различных кеширующих технологий, направленных на ускорение работы. Да, строить запросы важно, еще важнее оценить структуру базы и правильно проставить индексы, но это не значит, что можно забыть про кеширующие коннекторы к базе.
Мысли типа "лечение нагрузки - это вопрос тарифного плана" забавны. В высоко нагруженных решениях речь идет не о паре десятков баксов на другой тарифный план, а 3-4 килобаксов на дополнительный сервер... да и то в лучшем случае... а если еще окажется, что на FC свиче кончились порты и т.д и т.п... пару часов оптимизации могут сэкономить эту сумму.
Алексей Шеин
41 сообщение
#17 лет назад
Chevron, а чем Smarty может здесь помочь? Разве только кэшированием страниц... За Fusebox спасибо, почитаю.
miksir, можно поподробнее о кэширующих технологиях?
Большое спасибо всем ответившим.
Miksir D.
10 сообщений
#17 лет назад
Речь о кэшировании запросов. Тут речь не идет о том, что сам мускуль может кэшировать селекты - это тоже надо знать и использовать, но кэширование на стороне скриптов дает большую гибкость.
Т.е. результаты частых запросов держатся в памяти или в файлах какое-то время. И скрипт обращается за ними к базе только если память пуста или старая. Это общий принцип - кто как реализует - не знаю, я больше Perl программист. Для кэширования в памяти у PHP есть решения, типа memcached ()
А вообще, критерии больших нагрузок у всех разные. Для кого-то тысяча уникалных человек в день - огого, а для кого-то тысячи хитов в секунду - норма.
Для начала, просто старайся писать чисто и структурировано - это поможет не забывать что было 200 строчек кода назад.
Раду М.
159 сообщений
#17 лет назад
Цитата ("conf"):
Chevron, а чем Smarty может здесь помочь? Разве только кэшированием страниц... За Fusebox спасибо, почитаю.
miksir, можно поподробнее о кэширующих технологиях?
Большое спасибо всем ответившим.


1. Кэширование страниц
2. Новые "особенности архитектуры приложения"
Раду М.
159 сообщений
#17 лет назад
Цитата ("miksir"):
Мысли типа "лечение нагрузки - это вопрос тарифного плана" забавны. В высоко нагруженных решениях речь идет не о паре десятков баксов на другой тарифный план, а 3-4 килобаксов на дополнительный сервер... да и то в лучшем случае... а если еще окажется, что на FC свиче кончились порты и т.д и т.п... пару часов оптимизации могут сэкономить эту сумму.


Вывод не менее забавен, примеры таких проектов на PHP в студию!!!
ЗЫ: Такие проекты поднимаются другими технологиями, так сказать промышленными и используются не в интернете а немножечко в других "корпоративных" инсталяциях, PHP на это не тянет, увы. Не забывайте про что спрашивает автор.
Дмитрий Вашкевич
35 сообщений
#17 лет назад
Цитата:
Вывод не менее забавен, примеры таких проектов на PHP в студию!!!

Например, любой сайт на базе Битрикса, использующий кривонаписанные модули.
Было на одном сайте... Выборка данных всех пользователей определенной группы. Алгоритм был "красивый":
- Получение списка id нужных пользователей (типа SELECT id FROM table WHERE group=any)
- В цикле прокручивались айдишники и добывалась строка из этой же таблицы с таким id

Когда сайт заработал и пользователей оказалось около десяти тысяч...... В общем, руки таким разработчикам надо отрывать...
А у битрикса была функция, позволяющая всё это сделать одним запросом к базе. А именно, выполняющая запрос (SELECT * FROM table WHERE group=any)...
Раду М.
159 сообщений
#17 лет назад
Цитата ("Churchik"):
Цитата:
Вывод не менее забавен, примеры таких проектов на PHP в студию!!!

Например, любой сайт на базе Битрикса, использующий кривонаписанные модули.
Было на одном сайте... Выборка данных всех пользователей определенной группы. Алгоритм был "красивый":
- Получение списка id нужных пользователей (типа SELECT id FROM table WHERE group=any)
- В цикле прокручивались айдишники и добывалась строка из этой же таблицы с таким id

Когда сайт заработал и пользователей оказалось около десяти тысяч...... В общем, руки таким разработчикам надо отрывать...
А у битрикса была функция, позволяющая всё это сделать одним запросом к базе. А именно, выполняющая запрос (SELECT * FROM table WHERE group=any)...


А причем здесь "на FC свиче кончились порты"? Придерживайтесь контента пожалуйста
Miksir D.
10 сообщений
#17 лет назад
Цитата:
Такие проекты поднимаются другими технологиями, так сказать промышленными и используются не в интернете а немножечко в других "корпоративных" инсталяциях, PHP на это не тянет, увы.

Как вы думаете, работают большие порталы... думаете, на одном сервере? Боюсь, Вы с ними не общались. Да, есть способы гораздо большего снижения нагрузки на железо, чем оптимизация ПХП. Например, написать все на Си. Но во-первых, и тут один сервер будет мало, а во-вторых, если участвовали с больших проектах на Си, да еще в команде, да еще с поджимающими сроками... поймете чем лучше ПХП.
Цитата:
Не забывайте про что спрашивает автор.

Автор спрашивает, на что стоит смотреть при работе с проектами высокой посещаемости. Ему ответили.
Вы сказали, что вопрос решается железом - и Вам ответил я, что высоко нагруженные проекты на хостингах не живут, а их минимальная оптимизация способна сэкономить несколько тысяч $.
Кто в теме оптимизации кода и готов стать ведущим программистом в разработке высоко нагруженных веб-ресурсов - велкам, моя вакансия все еще открыта.
Miksir D.
10 сообщений
#17 лет назад
Цитата:
А причем здесь "на FC свиче кончились порты"? Придерживайтесь контента пожалуйста

Вот может Вы не в курсе, но построить нормальный кластер без общей дисковой системы сложновато... а FC остается единственной надежной реализацией этой задачи.
Miksir D.
10 сообщений
#17 лет назад
Полагайте
PS: кстати, расскажите тогда уж, как же правильно работают высоконагруженные веб-проекты.
Думаю, всем интересно будет... глядишь, и я в очередном проекте не сделаю ошибок =)
Алексей М.
1 сообщение
#17 лет назад
Было лень читать, поэтому быстро пробежался, но как мне показалось никто не сказал про асинхронное выполнение кода, конечно такие страницы идеально подходят для выполнения операций требующих времени, и я не уверен что это выход в данном в случае, хотя смотря что подразумевается под сильнонагруженным сайтом. Точно могу сказать - если сайт совершает сложные запросы в базу, а тем более в удалённую базу, то следует выбрать ASP.NET 2.0 + асинхронные страницы!