Как минимум странно мерить производительность хостинга скриптом, который выпущен одним из хостинг провайдеров да ещё и обфусцирован ionCube.
Я ни на что не намекаю, но можно очень выгодно сделать
if ($hosting == 'best.com') { $score = 296 - rand(0, 10); }
Намного правильней делать стресс-тест через siege или wrk, и смотреть Requests Per Second и Average Response Time.
_SP_, с базой напрямую работать признак дурного тона.
Как уже сказали, есть API (внутреннее) и есть REST API.
Marat_Kh, на самом деле нужен. Для всяких интеграций.
Магазин - это бесконечные процессы. Каждый день работа над конверсией, смена дизайна, редактирование остатков, акции и промокоды, контекстная реклама, etc.
Все это не сделаешь за 3-7 дней. За 3-7 дней будет магазин, который лучше сразу похоронить.
Делайте как хотите, главное добейтесь работоспособности. Не говнокод у вас сейчас не выйдет. Потом все перепишете, и не раз. Главное - делайте выводы, улучшайте, расширяйте. Ещё выучите ООП, а также SOLID и GRASP. Так быстрее придете к красивому коду.
Рефакторинг - практически бесконечный процесс.
Есть утилита siege, создана специально для нагрузочного тестирования. Там есть возможность отправлять POST запросы, а также указать количество потоков.
kxk, ну да, делали магазин на Laravel, влили около мульта, запускали, трафик лили, но так и не пошел. Потом нам дали совет про Yii2, переписали с нуля, задеплоили, и как поперло! Вот прям насперс завтра выкупаем!
Вообще, с вашей идеей о программисте в офисе я согласен. Но инструмент (Yii, Laravel, Flask, etc.) может быть абсолютно любой.
Т.С., а что вы хотели? Покупая CMS, вы связываете себе руки. CMS это для быстрого старта. Чтобы протестить нишу. CMS обязывает вас вписываться в архитектуру, использовать хуки, обновлять ядро, а это значит, что не все задачи можно решить. Вам нужно отталкиваться от бюджета: либо вы вбухаете денег, и сделаете себе ERP со всем нужным вам функционалом, либо вы тратите 30 тыс и покупаете CMS, в которой многое уже сделано, но это "многое" слишком размазано и не конкретно. CMS это как мультитул - там есть все, отвертки, мини-ножницы, открывашка для пива (это все плагины), но когда вы охотитесь на медведя, вам нужен специальный нож.
Не в защиту Wordpress/wooCommerce, т.к. сам не в восторге. За бугром, скажем, его часто используют. Но в специфических кругах: либо это магазины клубной атрибутики (магазины при блоге), либо это какие-то дизайнерские бутики/мелкие ритейлеры. Киты, конечно, сидят на Magento, demandware, самописы, etc., но это не значит что wooCommerce не применим для своих задач. Главное инструмент выбирать правильный.
В бизнесе есть KPI: это рентабельность инвестиций, прибыль. Если переход с wordpress на магенто не рентабельный, никто не будет этим заниматься. Magento очень дорогая в поддержке, во-первых, под неё нужен сисадмин, во-вторых, под неё нужен выделенный сервер, в-третьих, под неё нужен толковый программист. Там не получится наговнокодить, как, скажем, на Wordpress, потому что порог вхождения выше. И если магенто дорого, то самопис ещё дороже, если магазин действительно будет развиваться. Конечно, если написать корзину, товары, категории, личный кабинет, и оставить как есть, то стоимость поддержки стремится к нулю. Но стоит вписать туда, скажем, upselling, и цифра будет разнится. Для wordpress и magento это пара кликов. Для самописа - это 2-10 часов программиста. Это я к тому, что то, что используют крупные игроки, равносильно смерти использовать на старте или чуть позже. Бизнес должен приносить прибыль, используя при этом именно тот инструмент, который лучше всего подходит. И не всегда в этом случае выигрывает Magento.
Оптимизайка, а чем сайт вообще занимается, хоть приблизетельно: SAAS, новостник, блог, etc.? Load Average в пике 0.25? Для 4 ядер это-же смех. А RAM как используется?
Dimka, вот это действительно HighLoad. Perl вообще не ожидал увидеть. По поводу генерации страницы скриптом, согласен. Актуальность нужна на всяких сайтах с Real-Time чартами, статистикой, etc. Даже новости можно (даже нужно) кешировать, а при добавлении сбрасывать кеш. Ещё классная фишка - обмен данными с сервером через Protobuf или JSON. Экономит трафик и время ответа сервера, т.к. шаблоны на клиенте отрисовываются. Даже быстрее чем статику с диска отдавать. Хотя ещё быстрее - хранить статику уже отрисованную в памяти RAM и сразу её отдавать. Тут даже с данными работать не нужно.
А как вы картинки быстро на статике переключали? Прилинковывали другой каталог?
