Нужно ли оптимизировать скрипт?

Question

[Антон Медведев]

Всем привет!

Пишу чат на php с использованием Doctrine ORM. Так вот сейчас время генерации страницы в среднем 0.1 секунды. При этом расходуется 3.25МБ памяти.



Как вы думаете нормальное ли это время ответа для чата?

Как возрастет нагрузка при большом количестве подключений?

Или ajax-овую чать нужно переписать на чистом php?

PS PHP используется только для отправки сообщений. Загрузка работает через node.js.



Спасибо.

Comments

[Константин]

А таг Symfony здесь зачем? Почему всё не делается на node.js?

Answer 1

[Анатолий]

А Вас устраивает такое время? Если да, то не нужно, если нет, то нужно оптимизировать. Нет идеальных цифр, есть допустимые цифры, и если эти цифры переходят допустимый предел, то оптимизируют, иначе нет.

Answer 2

[quantum]

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

Есть еще и инструменты для нагрузочного тестирования. Если результат тестирования не удовлетворит, то переписывать или оптимизировать.

ps наверняка ниже будут комменты двух видов: «Вы что, отправка сообщений в чат, какая нафиг доктрина, оверхед, пушкой по воробьям» и «только правильно, только доктрина, скорость разработки важнее, а если на другую бд придется перейти?, паттерны, ооп, раби-раби-раби» :)

Comments

[Антон Медведев]

Каким инструментом можно сделать нагрузочное тестирование?

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

[Алексей Сундуков]

Инструментов достаточно в принципе. Это и ab, и JMetter то же. Лично я для себя выбрал httperf. Пример такого тестирования: Smarty VS ctpp

Answer 3

[Dunadan]

Мы у себя в чате добились отправки сообщения за 0.04 секунды.
php + MySQL.

В Вашем случае лучше подумать над не столько Доктриной как таковой, сколько над архитектурой приложения. Как именно у Вас получаются сообщения конечным пользователем?

Comments

[Алексей Сундуков]

Это на сервере столько ответ генериться, но как долго он идет до клиента? Long polling? WebSocket?

[Dunadan]

Long Pooling. Сокет держится где-то в районе 15 секунд (демон, как и у автора поста, на Ноде. У нас разделено понятие «отправки», то есть изначально запрос идет на Ноду, нода внутри себя проксирует ее на локальный пхп (сей изврат нужен для бизнес-логики, к моменту отправки подвязано вычисление рейтингов и других плюшек). После завершения запроса на постинг фразы идет «прочтение» новых мессаг и раздача подключенным клиентам.

[Алексей Сундуков]

Понятно. Сам хочу заюзать аналогичную схему. Но я выбрал erlang в качестве сервера держащего коннекты с клиентами. Слишком уж заманчиво выглядят дополнительные плюшки в виде ejabberd и rabbit. Ну и тема с миллионом коннектов с одного сервера тоже в принципе известная.

[Dunadan]

Ну вот про «миллион» коннектов всегда было интересно послушать — с учетом того, что количество открытых TCP/IP соединений в ОС все-таки ограниченно, если мне не изменяет память.
«Рвать» коннект приходится из-за кеширующих антивирусов :(

[Алексей Сундуков]

Не изменяет. По дефолту на «дефолтном» лине все жесткими лимитами заданно. И конечно это требует тюнинга стека. Но я к тому, что сама платформа на это способна.

Перевод статьи был даже на хабре: Comet–приложение для Mochiweb c нагрузкой в 1 000 000 пользователей, оригинал: A Million-user Comet Application with Mochiweb. Пару лет назад меня это вполне впечатлило, поэтому использовать что-то другое желания нет. Виртуальная машина пашет стабить и надежно. Как с этим у ноды? Сколько онлайнеров держит и каких ресурсов требует? И падает ли?

[Dunadan]

У нас — виртуалка под Win 2008R2. Выше 1500 одновременных реальных соединений не видел. Не падала «сама по себе», менеджер ноды IISNode ее перезагружает каждые Х запросов. На 1500 отъедало в районе ~75 Мб ОЗУ и 8% проца.

Answer 4

[Stdit]

Если в чат планируется отправлять больше 10 сообщений в секунду, или сервер чем-нибудь ещё занимается — тогда стоит. А вообще конечно тяжеловато для чата, можно на порядок улучшить и время и память. Кстати, APC или другой акселератор у вас поставлен?

Comments

[Антон Медведев]

APC да, поставлен. Это вместе с ним.

[Анатолий]

Ну будет 20 сообщений слаться в секунду и что? Запросы постоят в очереди, отправка задумается 0.1 дольше чем нужно у последнего, 0.2 вместо 0.1. О боже! Да это же убийство просто! Я не могу так долго ждать!!! Даже если на секунду задумается отправка и что? Просчитайте в голове одну секунду, и? Вы постарели? У Вас появился за это время ребенок?

[Stdit]

Эта ситуация верна для конкурентных запрсов, если в среднем их меньше 10ти. Для конкурентных запросов время ожидания будет терпимым (хоть и заметным пользователю). Если среднее количество запросов в секунду в среднем больше 10ти, то очередь будет расти и в конечном счётё положит сервер.

[Stdit]

Кстати APC.stat = 1 или 0?

Answer 5

[Антон Медведев]

Сообщения получаются не через php. Только отправляются. Архитектура как я считаю более мение правильной: фронт контроллер, роутер, котроллер, доктрина, ответ (короче слизана с симфонии :) )

Comments

[Dunadan]

Как Вы передаете сообщения с пхп в ноду?

Answer 6

[Vladislav Klimanov]

Как возрастет нагрузка при большом количестве подключений?

проведите стресс тест, если результат не удовлетворит, то надо оптимизировать