Всем привет! PHP занимаюсь уже достаточно давно, так что вопрос несколько не для новичков, но в любом случае должен быть им интересен.
Итак, какие моменты нужно учитывать при разработке PHP-скриптов, рассчитанных на большую нагрузку?
Всем привет! PHP занимаюсь уже достаточно давно, так что вопрос несколько не для новичков, но в любом случае должен быть им интересен.
Итак, какие моменты нужно учитывать при разработке PHP-скриптов, рассчитанных на большую нагрузку?
Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.
6 апреля 2008 в 0:05
Ребята ой как Вас несет то
to [Zloy]
1. Для hi-load проекта, я бы лично стал использовать постригс
2. А strtr() быстрее str_replace() если уж на то пошло
3. +1
4. +1
И про кэширование +2
Кароче ребята кому интересен этот вопрос и автор темы слушайте [Zloy] он шарит.
А вот этих слушать не надо, их несет:
to FreshMix: Рекомендую тебе писать научную фантастику или киберпанк. У тебя очень хорошо получается запоминать умные слова и термины и придавать им новый, какой то мистический, смысл.
—
>Четвертое, использовать классы, только тогда, когда без этого не обойтись, классы, чуть медленнее, но удобнее, и всё таки это ООП, нужно их использовать, но вмеру
—
Это из серии: Яблочное пюрэ может убить человека. (а здесь маленькими буквами дописать: если его ввести внутривенно.)
to andgein: На больших сайтах, где количество запросов в минуту превышает хотя бы 100, с одной страницы отправляется не более 2-х точно составленных sql запросов. Иначе разработчики мудаки и сайт их гавно. А дальше пошла научная фантастика, но видимо что то более интелектуальное, чем у FreshMix, вам молодой человек надо соавтороми быть с FreshMix.
28 марта 2008 в 8:02
На больших сайах, где количество запросов в минуту превышает хотя бы 100, к серверу MySQL бывает много запросов. На самом деле, Apache лучше настроен на многопотоковую работу (это связано с некоторыми особенностями работы MySQL) и в таких ситуациях благоразумнее будет пользоваться средствами PHP, а не SQL. Пусть уж он быстро обработает… Ну и что, выдаст огромный массиы данных. Если сервер позвояет, на время обработки это не повлияет, а вот на освобождения ресурсов компа очень даже….
12 марта 2008 в 1:05
Ой, ну бывает… Ктож не опишется… Да, регулярки будут работать медленнее но в некоторых случаях не обойтись только маской…
И всё же для очень больших баз данных, свыше 1 000 000записей, такой поиск очень жесток
11 марта 2008 в 12:04
Опыт, конечно, хорошо, но мне лично это кажется странным, что регулярки быстрее масок. Мускуль всё-таки не индусы делали. =) Можете как-то обосновать свою мысль?..
18 января 2008 в 15:05
[QUOTE]в третих, приходилось видеть, да и сам так поначалу делал – для поиска в таблице, не выдирайте всю таблицу с целью дальше ее пропарсить средствами php – сделайте это на уровне SQL – SELECT `col` FROM `table` WHERE `name` LIKE '%blabla%'[/QUOTE]
Уважаемый Сергей MY UNDERSIDE Малыхин, использование поиска по маске очень жрёт ресурсы сервера, никогда не советовал и не буду искать таким способом инофрмацию по большой БД…
На собственном опыте доказано, лучше использовать регулярки в SQL запросах
16 октября 2007 в 2:04
идеологические советы по производительности:
1) не юзайте mysql_result() (юзайте mysql_fetch_array\assoc)
2) Старайтесь не прибегать к использованию рег. выражений там где это можно обойти, даже если вместо 1 preg_replace придется вбить 10 str_replace()
** по своему опыту: использование рег. выр. например в CMS – практически не понижает производительность. Другое дело если у вас стоит задача сгенерировать несколько тысяч разных html страниц за 20 минут (к примеру). В таких случаях для обработки контента лучше использовать str_replace() все таки вместо preg_repalce() где это возможно. preg_match_all() как правило создает меньшую нагрузку из за специфики использования **
3) используйте связку вебсерверов ngix+apache2 – ngix будет отдавать статику, апач обрабатывать динамику
4) при запросах в мускул типа SELECT
во первых старайтесь не юзать SELECT * FROM – "*" обозначает что извлекаются данные из всех столбцов, аэто не всегда нужно. SELECT `col1`,`col2` FROM
во вторых, указывайте в конце SELECT запроса LIMIT – если только вам реально не нужно выдернуть всю таблицу
в третих, приходилось видеть, да и сам так поначалу делал – для поиска в таблице, не выдирайте всю таблицу с целью дальше ее пропарсить средствами php – сделайте это на уровне SQL – SELECT `col` FROM `table` WHERE `name` LIKE '%blabla%'
и еще, у себя замечал, что если в скрипте есть какой либо ресурсоемкий цикл, то полезно в конце вставить sleep(количество_секунд_простоя) – стабилизирует нагрузку (не относиться к скриптам, выдающим на данные на лету, но в таких как правило и не используется ресурсоемкие циклы.
если ваш скрипт должен что то выводить на экран постепенно (например результаты парсинга страниц с удаленного сервера) – вставьте в начало кода ob_implicit_flush()
и последнее – юзайте кеширование. везде где можно
я высказался, бейте ))
16 октября 2007 в 2:04
Сергей FreshMix, разрешите высказать свою позицию по вашей точке зрения:
1) "поиск ошибок." все же имхо ошибки нужно искать не в целях повышения производительности а в целях удаления ошибок =) в идеале, интерпретатор должен при error_reporting(E_ALL) молчать)
2) на самом деле это очень незначительно… только если конкретизировать так: лучше убивать переменные через unset($var) в тех случаях когда они далее уже не используются в коде. например массивы по 30 мб =)
с 3 и 4 полностью соглашусь =)
7 октября 2007 в 16:05
Я вот олько начинаю изучать php. Достаточно интересно, но, естественно, огромное количество вопросов. Как сгруппирую их, выложу. FreshMix, обязательно воспользуюсь твоими советами.
7 октября 2007 в 13:03
Здрасти…
Первое о чем я подумал, чтоб ответить на ваш вопрос – это поиск ошибок. PHP очень снисходителен к ошибкам, просто ошибочный код может работать, но эти ошибки отрабатываются что ведет к чуть большему времени работы, к томуже ошибка может вырости.
Второе, намерное как можно меньше использовать переменных.
Третье, нужно использовать встроенные функции языка, они быстрее, безошибочнее, и их огромное количество на все случаи жизни.
Четвертое, использовать классы, только тогда, когда без этого не обойтись, классы, чуть медленнее, но удобнее, и всё таки это ООП, нужно их использовать, но вмеру.
но это ИМХО… =)