WebDev

у мускуля несколько кэшей. Кэшироваться может как план исполнения запроса, там и данные.
наиболее интересно данные - в 99% случаев наиболее значитмый эффект.

а у Вас, судя по описанию, либо запросы повторяются не слишком часто (и данные из кэше вытесняются), либо кэш небольшой (и он, опять-же, чистится)

попробуйте запустить mysqltuner и посмотрите на "Query cache prunes per day"

Несколько дивов, в каждом часть картинки, например с помощью background-position
дальше css анимация этих дивов

Хранить картинки в базе - это очень плохой подход. Если у Вас это делает библиотека - тогда это плохая библиотека. Почему плохо хранить картинки в базе?
1. Вы увеличиваете объемы данных передаваемые из СУБД в приложение, что в последствии скажется на производительности
2. Объем таблицы в базе имеет ограничение, а при сохранении в нее картинок Вы сильно рискуете превысить это ограничение.
3. Вы не сможете производить множество действия над полями с картинками (сортировать, делать выборки над ними)
4. Если Вы делаете веб-приложения - тогда при таком подходе можете забыть о кешировании, т.к. его Вы полноценно не сделаете.
5. Распределение изображений на разные серверы для оптимизации скорости загрузки так же не получиться сделать.

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

Доброй ночи.
Да, в отличии от windows на ubuntu терминал на первом месте, главнейший инструмент.
Чтобы отредактировать файл, не обязательно вообще запускать gedit, можно через тот же терминал
sudo nano /etc/nginx/nginx.conf
Что за зверёк такой "nano" читайте здесь
И вообще, привыкните к терминалу, научитесь работать в нём и все девушки/парни(нужное подчеркнуть) - Ваши)))))

*************************************************
Через консоль можно не только редактировать, создавать, копировать, перемещать файлы внутри системы, но и на удалённом сервере через терминал можно творить чудеса.

1
2
3
4

**********************************************************************
Чуть не забыл.
Помните, что работая через терминал нужно думать головой и прежде , чем выполнить какую либо команду - читать документацию.

Поясните вопрос. Если по поводу DB::raw, то он поддерживает плейсхолдеры и вторым параметром он принимает данные.https://laravel.com/docs/5.2/database

Типо да. Заурядный и тупой. Ограничить количество коннектов и ограничить время на логин-сессию, запретить логин рутом по ssh (от слова совсем - даже при знании правильного пароля). Если есть возможность - ограничить по IP, настроить логин по ключам вместо паролей.

Дык у вас лог sshd приведен. При чем тут nginx
Да - это обычный брутфорс ботами. Быстрее всего пробегутся по списку наиболее распостраненных аккаунтов и паролей, и переключатся на другую жертву.
Вынесите порт ssh на нестандартный, и прикрутите какой-нибудь fail2ban

Самое простое поменять селектор ссылок на такой:
a[href^="#"]

"one-two-three-moscow-zao" А у тебя PHP должен ванговать что-ли, то что ты хочешь вытащить??? С таким паттерном как у тебя в маршруте в самих варах не должно быть тире, а они есть. Так что твой шаблон максимум сработает для ровно трех-слоганного слова. Во-вторых, нахрена тебе разделять эти переменные прямо в маршруте?

Я напишу решение, но если такие базовые задачи ты решаешь так, то это не твое.

Route::get('/{category}/{title}', 'Site\CategoryController@getSubCategoryIndex_test');

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

С таким подходом как у тебя сейчас реализовать это НЕ ВОЗМОЖНО.

Почему так происходит?
1. Потому, что выводится в результате меньше ровно на (2 000 000 - 20) записей.
Или, другими словами, диапазон: 1 999 980 ... 2 000 000
2. Обратная сортировка 'desc' - смотрит в диапазоне от >='2016-01-24' до последней (самой новой) даты и сортировку этого списка - реверсирует, чтобы начать перебор с конца, поэтому кол-во просматриваемых записей - тут НЕСОИЗМЕРИМО! меньше и из-за этого запрос работает быстрее.

Да всегда, выигрываете время на перестраивании индексов. У меня выигрыш где-то в 40 раз был.

При этом "узким горлышком" производительности веб приложений как правило является именно БД.

Логично, ведь большинство веб-приложений это выборка с некоторой простой обработкой. А БД не все умеют хорошо спроектировать.

Имеет ли смысл сортировать и группировать результаты выборки с помощью ЯП, чтобы убрать сортировку и группировку из запросов?

Это имеет смысл только если у вас вообще нет индексов, и по каким-то непостижимым причинам вы не можете их добавить. Чтобы отсортировать быстрее СУБД, нужно построить индекс самому, а вы вряд ли сделаете это лучше СУБД, еще и так, чтобы покрыть расходы на передачу данных. Группировку имеет смысл только если агрегирующая функция вычислительно очень сложная, но такое вы скорее всего в SQL запросе писать и не будете.

Даже если у вас sort и group действительно занимают основной процент времени, перенос этих операций в код приложения врядли вам поможет. Иначе говоря, пока вы добьетесь приемлемого результата от такого решения, вы добрую часть алгоритмов СУБД перепишите заново (сначала вы напишите индексы для поиска или сортировку слиянием, потом, как заметил Сергей Савостин у вас всё равно данные не будут влезать в ОЗУ и вы захотите писать их на диск, тут же вашу копию данных в приложении нужно будет синхронизировать и вы начнёте писать примитивную репликацию и так далее..)

не значит: емнип, все апдейты 5.6 - это багфиксинг.
лучше конечно обновиться, но, как правило, не критично.

1. git.blivesta.com/animsition
2. jquery fadeout/fadein

1) это не юнит тест, это интеграционный тест. Он проверят "часть системы в сборе", в вашем случае апишку. Если бы вы тестировали через UI (то есть через ангуляр) - это называлось бы end-to-end тест (от кнопок до базы данных мол).

2)

На просторах инета вижу простые примеры тестов которые проверяют на true false

Давайте думать. Вот как бы вы проверяли такое руками? Можете придумать? А теперь можете написать скрипт который проверяет это за вас? Вот вы и умеете писать интеграционные тесты, это не очень сложно. Нужно только не зацикливаться.

Что вам по сути важно когда вы пишите апишку? Скорее всего вы хотите всегда знать что структура ваших ответов не сломалась. Что вы случайно не поменяли имя поля, или случайно не убрали нужные поля. Для этого есть такая штука как json schema. То есть мы берем json и проверяем на соответствие. Опять же для phpunit можно найти готовые ассерты что бы не пилить велосипед.

Далее, что еще нам может хотеться проверить - статус коды. Это опять же легко и думаю в документации к laravel это есть. Так же возможно вы захотите проверять заголовки но это уже специфичные штуки.

Словом все что вы хотите проверить - вы просто проверяете. Правильно - это когда оно выполняет ваши потребности.

Ну и возможно вам захочется проверить данные в json ответе. Тут уже есть кучи вариантов. Я например запилил свой велосипед для частичного сравнения JSON-а (ну не интересно мне все проверять). Можно и другими решениями это делать, но лично я такие штуки на этом уровне проверяю крайне редко, ибо... ну у меня другие тесты за проверку логики отвечают.

stackoverflow.com/questions/5431905/how-to-hide-a-...

Скажите другу что с php-то толком и не работали, он вас поймет и так будет лучше всем