Какие действительно классные сайты сделаны на Phalcon?

Question

[Александр Иванов]

Мне очень хочется верить в то, что phalcon может состязаться с node.js.
Однако на текущий момент я не встречал ещё действительно классных и шустрых сайтов на нём.

а на этом сайте многие проекты слишком сырые либо просто криво реализованы.

Поделитесь кто что встречал.

Я пока видел только что-то вроде этого www.24sata.rs
Там многосайтовость и загружается норм но после клика где-нибудь 8-10 скорость уже на спад идёт.

Comments

[Владимир]

А не путаете вы бек и фронт?

[Александр Иванов]

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

Или вы что-то другое имеете в виду?

[Артем Кисленко]

А как вы скорость замеряли? Смотрели время ответа сервера или так - 'на глаз'? Вопрос, конечно, абсолютно некорректен, правильно сконфигурированный сервер с php на борту и оптимизированным кодом внутри, даст фору кривому приложению на ноде на слабом сервере (вариации здесь возможны). Php вполне себе может конкурировать с nodejs по скорости, если это обычное клиент-серверное приложение все упрется в скорость работы с БД и другие какие-нибудь детали реализации. А если это "супер-навороченный" интернет-магазин, все упирается в кучу скриптов и больших картинок, т.е. ответ сервера 200мс, а сайт отрендерился за 12 сек. Так что ОБЫЧНО фреймворк дело десятое.

[xmoonlight]

Артем Кисленко: обычно скорость возрастает, когда неправильно распределяют нагрузку на серверную и клиентскую части.
Т.е. оптимально делать так: сервер работает с данными, браузер - с рендерингом GUI.
Банальный пример: изображение. (lazy load - это последовательность загрузки при просмотре - пока не трогаем - это вообще отдельный трактат)))))
Вопросы:
1. В каком разрешении вставлять изображение?
2. А давайте загрузим как есть, а на клиенте проценты выставим для IMG. Пойдёт так?
3. Давайте сегментируем: будем хранить 2-3 разрешения одного и того же изображения
4. А для ретины - как подгрузить с лучшим качеством?
5. А как сделать чтобы еще и не забрали?

Да ответ прост: запрашивайте ту часть потока исходного изображения с сервера (который хранит изображение в максимальном разрешении), которая требуется в данный момент с учётом размеров контейнера IMG.
Достаточно добавить динамически к src размеры контейнера перед запросом к серверу, а на сервере - обработать поток изображения с нужным шагом и вернуть готовое изображение. Кэшировать просто: hash([путь с именем файла]+[размер изображения: W*H])
Вот тут - серверное кэширование сработает более, чем на 100%!
Ресайз view-port'a - (все действия на клиенте) сразу запрос на подгрузку нового в отдельный поток и растяжение текущего, эффект как в youtube, когда меняется разрешение "на-лету" при начале просмотра в режиме full-screen.

В чем тут основная проблема? В том, что нужно динамически формировать форматы (JPG,PNG) из бинарных данных на сервере с учётом параметров в запросе (+кэшировать).
Да, и никаких ресайзов на сервере быть не должно! Процессор нам еще нужен для других операций)
Только пропуск потоковых данных с учётом шага: через X%N. Например, уменьшить в 2 раза: X%2 и т.д.

Answer 1

[xmoonlight]

Вы ищите сферического коня в вакууме.
Всё зависит в первую очередь от кодера, а только потом - от фреймворка.
Берите один алгоритм и тестите: на ноде и на фалконе, и уже полученное - сравнивайте.

Comments

[Артем Кисленко]

Я дополню немного ответ, кроме кода важно как будет настроен сервер сюда же входит и БД, потому что тот же php - взял php-fpm и nginx поставил количество ядер и не паришься, все работает. А nodejs по-умолчанию на одном ядре работает, тут еще нужно все правильно настроить, чтобы все хорошо было и ул запросов к БД корректно работал и т.д.. Так что оптимизация сервера тоже очень важно.

[xmoonlight]

Артем Кисленко: Очень верное замечание! Спасибо!