Friday, February 20, 2009

Размышения о php, его применении

Статья о моих метаниях в процессе разработки и правильном использовании PHP.

Для затравки желательно прочитать статью 10 принципов PHP специалистов.

В принципе ничего нового. Теперь что думаю я.

1. PHP медленный язык. И не надо рассказывать о том, что большую часть времени занимает работа с базой, мемкэшем, файлами и т.д.
Даже вызов PHP фукнции достаточно дорогая операция. А уж подключения библиотеки - кошмар.

2. Фреймворки - монструозны, а если это сложить с пунктом один, получаем, что они еще и тормозны по определению.

Исходя из этих требования, а также под угрозами бешеных нагрузок я участвовал в написании проекта, который был минималистичен в плане порождения сущностей. На удобстве и скорости разработки это мало сказалось, т..к была изобретен минимальный фундамент (велосипед), который не давал скатиться в написание портянок. Зато время генерации при небольшой и средней нагрузках было 0.01-0.03 сек. Но т.к. администратор выбрал распределённую фс, это выразилось в подскакивании времени генерации до 0.1 сек.

В ходе этого я выяснил.

3. Проблемы описанные в пп 1,2 неприятны, но решаемы, в основном кэшированием и настройками серверов, или отказом от PHP.

Скажем так, оптимизация веб-сервера (отключение модулей апача, extensions php) дало прирост 10-20%, (смена апача на lighttpd +fcgi) дало прирост еще на 30%. Я бы не смог настолько оптимизировать код по всему проекту.

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

В итоге я ударяюсь (контролируемо) в другую крайность, в правильную разработку. Т.е. играемся с проектированием на всю катушку. Начинаем смотреть в сторону ОРМ уже в качестве необходимости.


Прошло время я наигрался и тем, и с другим. Сразу условлюсь что проект я предлагал делать на java, но руководство выбрало php по понятным всем причинам.

А теперь пример, который просто меня убил.

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

Итак, есть игрушки, которые потенциально кидают много запросов. Есть рейтинг игроков который нужно пересчитывать по определенным формулам.

Реализация на php:

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


Реализация на python:

Twisted server, который в памяти хранит пользователей, отсортированных по результатам. При новых результатах, пользователь удаляется из отсортированного листа, ему начисляется новый скоринг, и он вставляется в список. Сам сервер по xmlrpc умеет отдавать результаты - веб серверу.
Веб сервер работает на старом движке, вместо запросов к базе - запросы к xmlrpc-server.

Реализация - быстрее чем на php(по времени разработки и отладки), скорость работы - выше, удобство использования - выше.

Самый большой плюс, система работает online!

Из недостатков - новая сложность системы в виде нового сервера.

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


Также могу привести еще несколько подобных вещей. В общем мое мнение ниша PHP - это все-таки fron-end, который отображает информацию от кучи разнородных сервисов, где собственно и будет реализована вся логика.

4 comments:

Shtorm said...

Можно вопрос такого характера
Я полный новичок в web программировании.
Не подскажите какая система
удовлетворит такому проекту.
К примеру есть определенная структура данных , есть пользователи , объединненные по географическому принципу , которые могут как дополнять существующие данные , так и расслыть сообщения по некоторым георгафическим принципам , так и составлять произвольные группы для обсуждения разных вопросов .
Прошу прощения за некоторую сумбурность описания , пишу без подготовки :)

Unknown said...

Ну вопрос конечно из разряда кто виноват.

1. Определиться с задачей, в частности привести свои мысли в порядок, есть подозрение что вы сами не представляете чего хочется.
2. Попытаться найти готовые решения. Например рассмотреть вариант интеграции ( geoip + google maps + wiki + поискаь что то в сторону социальных сетей )
3. Оценить варианты из соображений, цены, времени и возможностей.
4. Если ничего не подходит отдать кому-то на разработку, или начать писать с нуля.

А вопрос какая система .... ну мне кажется какой то неправильный. Я думаю если подразумевалось готовое решение, гугл ответит лучше меня.

FatDevil said...

Полный треш написан.
Для Twisted фронтенд в виде похапе ненужен в принципе - достаточно lighttpd или nginx - благо есть twisted.web(2).

И уж явно похапе не сравнится с работой под нагрузкой с twisted.

Ниша похапе это домашние странички компаний с красивыми картинками и картой проезда. А уж никак как средства отображения данных с разных сервисов - с этим также куда лучше справится twisted/python.

Unknown said...

Уважаемый, для начала нужно внимательно читать а не кидаться с защитой того, что вы считаете святым.

Далее по пунктам.

Ваше : И уж явно похапе не сравнится с работой под нагрузкой с twisted. Опредленно говорит что вы не читали то что я написал, привожу цитаты 1. PHP медленный язык. и Реализация на python: быстрее чем на php(по времени разработки и отладки), скорость работы - выше, удобство использования - выше.

2. Ваше Для Twisted фронтенд в виде похапе ненужен в принципе А теперь внимательно читаем статью и видим что данное решение в виде PHP Frondend выбрано, в рамках текущего проекта, т.к. 95% кода уже реализованно на PHP, сервис подсчета очков реализован достаточно изолированно, не меняет бизнес логики основного сайта, но не обладает функционалом для получения информации необходимой для реализации frontend, а реализация его на twisted.web2 было бы глупой идеей из соображений поддержки 2-х версий портала,а не из-за того что я считаю питон и twisted плохими вещами (наоборот!). К слову говоря идея переписать портал на питон давно висит в воздухе, но останавливает оценка по времени - не менее года.

 
Каталог сайтов, Добавить сайт