Email or username:

Password:

Forgot your password?
Top-level
Andrey Pechorin

@iron_bug @bifik Человек дошел до того, чтобы как-то организовать нормальный процесс доставки и деплоя, а вы ему rsync советуете. Спасибо, не надо.

5 comments
BiFiK

@pechorin @iron_bug не стоит ссориться. Я ищу "дешевые варианты", а потом, если не нашел их - ищу варианты дороже.

Настраивать CI\CD для проекта, где 1-10 пользователей, а так же туда добавлять Reddis или Memcache для кеширования - ну ок, могу. "есть ли в этом толк ?".

BiFiK

@pechorin @iron_bug можно сказать, что я понял ряд "дешевых вариантов", которые можно "реализовать уже сейчас", но так же понял несколько подходов, по которым мне стоит будет почитать документацию и изучить вопрос более точно. Ну и так же найти варианты применения для максимального уровня "производительности, удобства и простоты".

Andrey Pechorin

@bifik @iron_bug redis с одной d пишется, вы уж извините.

Iron Bug
испоьзование кэша, БД и прочего зависит от того, что твой софт делает и как он это делает, а не от количества пользователей. и да, на начальном этапе может быть 1-10 юзеров, а потом вдруг софт станет популярен и их могут стать миллионы. практичеки весь опенсорц писали "для себя", а теперь от некоторых библиотек или утилит зависит практическески всё.
а в вебе БД - это обычное дело. для мелких задач это обычно мускуль (сейчас он Maria DB в формате СПО). вопрос выбора инструментов для PHP чаще связан с софтом на хостингах. люди редко берут выделенный сервер, чтобы хостить там сайт/приложение на PHP. обычно это веб-хостинги. и обычно веб-хостинг предлагает готовый суповой набор софта: несколько версий PHP и БД в виде мускуля. есть даже аббревиатруа LAMP - Linux, Apache, MySQL, PHP. потому что это самая типичная конфигурация и её многие используют. для небольших задач с малой нагрузкой она вполне работает.
с Редисом есть вопросы, потому что они недавно поменяли лицензию и теперь от них многие отказываются. вопрос вкуса, конечно, но теперь это уже не СПО, а что-то ближе к проприетарщине. но, в принципе, разных NoSQL баз довольно много и все они однотипные. хотя они довольно редко нужны в вебе из-за своей специфики.
разные MQ - это уже не базы, это совсем другая вещь - очереди сообщений. но очереди тоже бывают нужны, правда, в вебе я их как-то не встречала. хотя в обычном сетевом софте они встречаются периодически.
что касается PHP, при грамотном использовании он самый быстрый и производительный, если сравнивать языки, на которых пишут веб. но надо уметь на нём писать. потому что наговнокодить на PHP можно ещё как, и будет работать стрёмно и жрать ресурсы. честно говоря, я гораздо чаще видела тех, кто на нём писать не умел :)
Memcache и вообще кэши - вещь хорошая, когда уже есть софт, какой-то workflow и надо его немного оптимизировать под существующую нагрузку. БД тоже имеют свои настраиваемые кэши для этой цели, там кроме кэша есть разные средства для структуризации хранения самих данных по времени и географии (сегменты, разделы, кластеры и прочее), можно грубоко погружаться. собственно БД решают задачу извлечения данных по запросу и там многое сделано для того, чтобы это работало быстро и оптимально. но для маленьких сайтов и небольшой нагрузки это из пушки по воробьям. зависит от объёмов данных, конечно. я много работала с high load и когда у тебя миллионы юзеров и огромные данные, приходится оптимизировать каждый чих, вплоть до системных вызовов и спинлоков. вот этим я и занимаюсь, чаще всего. но в маленьких приложениях это было бы преждевременной оптимизацией. хотя никто не мешает стремиться к идеалу и улучшать качество софта. я даже маленькие утилиты пищу оптимально. мало ли где и в каком количестве они могут использоваться. в вебе неплохо экономить работу сервера (за счёт кэша, например) и стараться уменьшать трафик. современный плохо написанный софт в вебе создаёт колоссальные нагрузки на сеть и серверы.
испоьзование кэша, БД и прочего зависит от того, что твой софт делает и как он это делает, а не от количества пользователей. и да, на начальном этапе может быть 1-10 юзеров, а потом вдруг софт станет популярен и их могут стать миллионы. практичеки весь опенсорц писали "для себя", а теперь от некоторых библиотек или утилит зависит практическески всё.
Iron Bug
пардон, и чем же "плох" rsync? используется повсеместно, никаких проблем с ним нет. не жирен, не жрёт лишние ресурсы. это стандартная утилита, можно сказать.
да, люди придумали много ненужных костылей, которые жрут ресурсы и требуют кучу времени. но нормальые простые инструменты вполне есть и они работают.
Go Up