"Для обмена между клиентом и сервером" Есть альтернатива php?

Question

[nullname]

Решил улучшить производительность, переписал код по максимум на js, но столкнулся с такой проблемой, как обмен данными и их обработкой на сервере. Сейчас все нормально, использую php для "приема, обработки, проверки, записи, вывода, обновления, отправки,итд". К увы он не много тормозит, производительность скромная..

Что можно выбрать на замену php ??
Думаю что и серверную часть стоит переписать с php на js (note.js) но он для интерфейсов, а для push лучше использовать лонгпул.

что от языка надо:
Желательно простота изучения или похожий синтаксис.
Производительность.
Совместимость с базой , запросы: mysqli.

Функции:
обработка, валидация (ибо js не стоит верить),
вывод,
"запись,удаление,изменение, добавление"(как для mysql, так и для обычных файлов),
итд.

Может что-то упустил, сутра допишу.
Спасибо, за отклик.

Comments

[nullname]

Может есть ускорители для php или оптимизировать его?? Я правда отключил кэш.. на время теста

Answer 1

[Сергей Протько]

вы не думали что у вас проблемы с архитектурой а не с языком? Судя по всему у вас на сервере нет сложной математики. Так что все упирается в I/O. Вывод - вам PHP хватит с головой.

а для push лучше использовать лонгпул.

Кто вам такое сказал? Сисадмины которые режут весь не HTTP трафик?

Ну а если вам всеравно нужен "быстрый язык" и без разницы что вы им пользоваться не будете уметь - golang.

Comments

[nullname]

Есть и другой, но там все на вебсокетах... лонгпулл вк использует

[Сергей Протько]

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

Что до лонгпулинга - вы задавались вопросом почему?

[nullname]

Недосып, вы правы. Думаю что дело в базе или железе, потом отпишусь... Залил на свой сервак, тормозов нету.

[Сергей Протько]

nullname: если вы тестируете один то их может не быть за счет кеша базы данных. Под нагрузками же могут всплыть реальные проблемы.

[nullname]

Сергей Протько: Реальную нагрузку я знаю, оптимизация сняла 28%. Тестит бот, который создает еще 100 ботов и в принципи результаты не сильно отклоняются от нормы. Спасибо, не как не отменить как решение, странно.

Answer 2

[Сергей]

Пользуйте Erlang. Сперва тяжело, хотя и говорят что основы за 2 недели учатся. Но потом идет как по маслу. И longpooling и websockets и распараллеливание и демон в памяти, а не как в php: получил запрос-пошел в базу-отработал-все забыл, начал с начала.
Erl наше всё. А ваше ?

Comments

[nullname]

не, спасибо.

[# a r t u r #]

nullname: это точно

Answer 3

[Dremkin]

Проблема не в PHP - это точно, со всеми вытекающими..

Comments

[nullname]

А в чем? В базе? Код написан на 5+ ко всему 2 мес назад его проф. программисты оптимизировали.
Скажу что цп грузиться на 100% 2 ядра по 3,3ггц. При этом все действия на клиенте.. Php выводит, пересчитывает, записывает итд.. Подсчет итд это для проверки.

[Dremkin]

Может быть:
1. В структуре данных.
2. В методах обработки.
3. И еще черт знает в чем :)

Без просмотра вашего кода определенно можно сказать только одно - дело не в языке PHP.

[nullname]

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

[Сергей Протько]

nullname: на 5+ по 10-ти бальной шкале?

[nullname]

Сергей Протько: смешно.. Нет проверенные люди

Answer 4

[# a r t u r #]

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

Еще такой вариант: Вы тестируете на локалке и используете не настроенный OpenServer, а точнее с включенным IPv6

Comments

[nullname]

На хостинге, думаю что пора свой сервак брать, дело в железе, 8гб оперативки и 2х ядерный проц на 3.3 ггц, загрузка цп 80-100%

Answer 5

[larionov_n]

Дело точно не в php. Но если искать альтернативу то: Python (Flask, Django), Javascript(Nodejs + express).

Answer 6

[Виктор]

Я так понял вы обрабатываете соединения с webSockets на php и думаете что если перейти с webSockets на long polling то что то начнёт работать быстрее?
Нет быстрее от этого не будет, на оборот long polling по любому будет медленнее чем webSockets так как для отправки каждого сообщения по long polling требуется рвать соединение а в webSockets нет. процесс установки соединения не мгновенен, этого достаточно чтобы понять что webSockets реализация будет быстрее работать чем long polling.
Если это так то я рекомендую вам вынести работу с webSockets на что то другое, а всё остальное обрабатывать на php как и раньше.
А выносить работу с webSockets я рекомендую на какой нибудь comet сервер у которого есть php api. Прежде чем изучать другой язык и писать велосипед ознакомитесь с уже существующими решениями.

Есть готовые решения Dklab Realplexor или Ratchet, а есть ещё вариант аренды комет сервера по принципу SaaS, что гораздо проще а на не больших проектах ещё и дешевле.
[Ru] comet-server.ru
[En] pusher.com

Comments

[nullname]

Не, изначально хотел обмениваться данными с помощью webSockets, но после того как углубился, понял что он еще сыроват и не пришло его время. Так что использую long polling. Знаю что он медленнее.. к увы.. ajax еще медленнее..

[nullname]

p.s я знаю что long polling использует ajax

Answer 7

[k-maks]

У меня этим занимается Python в паре с WordPress. Легкий в понимании быстрый в изучении, удобный в отладке, + можно использовать Фреймворк вроде Django для "грязной" работы вроде генерации и обработки запросов клиент-сервер.

Answer 8

[ycexa]

Давайте и я в холиваре поучаствую)
Так как PHP - это интерпретируемый язык, он, действительно, не самый быстрый по-умолчанию.
Но нужно понимать, в чем эта "не быстрость" заключается. Состоит она в том, что php-интерпретатору перед выполнением кода требуется время на то, чтобы перевести его в байткод. Чтобы сэкономить на этом процессе используются php-акселлераторы (видимо, их ты и имеешь в виду, когда пишешь "отключил кэширование"). В остальном php - обычный высокоуровневый язык со своими особенностями.
Поэтому я соглашусь с другими участниками, что, скорее всего, проблема не в самой пыхе.

Когда ты пишешь:

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

Нужно понимать, что "немного тормозит" - это [время на отправку запроса] + [время на то, чтобы сервер передал запрос php-интерпретатору] + [[интерпретация кода] + [исполнение кода] + [обращение к файлам (например, если используется сессия, и хранится она файлово)] + [обращение к БД] + др.]] + [время на вернуть запрос]
Как видно, "переписать" в лучшем случае ускорит один из 7 этапов обработки ответа, а гемороя обещает очень много.
Поэтому я советую вначале разобраться с тем, что именно в текущий момент является узким горлышком. Для этого нужно использовать профилировщик (не путать с отладчиком)!
Самым наглядным, наверное, будет NewRelic. А вообще их целая куча. Например, xhprof

(То, что ты пишешь, что процессор занят на 100% именно пыхой - это не нормально. Либо пыха делает что-то лишнее, либо криво настроен сервер.
Учитывая то, что ты пробуешь играться с long-poll запросами, велика вероятность, что плодится очень много лишних деток)