Во-первых не все проходят этап собеседования. Во-вторых некоторые направления развиваются очень быстро и закрыть все руководящие вакансии только внутренними переходами не получается. Мне кажется, что текучка на руководящих должностях очень низкая.
Забавно, но не нашёл на хабре упоминания об этом даже в комментариях. Пора устранить этот недостаток, ведь многие используют только хабр, как источник информации.
Любопытно еще то, что после обновления изменилось поведение функции is_a. Раньше, если первым параметром приходила строка, то сравнение возвращался корректный результат.
<?php
class A {}
class B extends A {}
var_dump(is_a('B', 'A')); // false, но в 5.3.8 было true
var_dump(is_subclass_of('B', 'A')); // true, осталось как и было
Скажите, а что с поддержкой многоязычности? Если в проекте необходим поиск не только по русским текста, но и по арабским? Будет ли какое-нибудь движение в эту сторону?
Сейчас такая возможность реализуется через указание charset_table. Есть ли какие-нибудь более «правильные» способы для этого?
В случае с очередями теоретически их еще можно пытаться рассчитывать заранее, до того как придет пользователь, но в этом случае надо больше статистики и анализа, чтобы понять для кого и как их рассчитывать. Может быть рассчитав очереди для 20% активных пользователей ночью, когда народу мало, вы сможете разгрузить базу во время пиков, когда основной поток людей приходит к вам.
Да и в этот баланс еще входят трудозатраты на эту оптимизацию персоналом и последующая поддержка этого кода, что тоже крайне важно. Тут главное не перегнуть палку.
Да, и чем более популярным будет становится — тем больше записей будет появляться как в таблице фоток, так и в таблице голосов.
Из вариантов оптимизации могу лишь предложить перед входом пользователя сразу подготавливать ему очередь фоток из 10-20-30, за которые он не голосовал и потом их постепенно ему отдавать. Сколько фоток за сессию отмечает пользователь вы из своей статистики должны знать. Такой вариант будет грузить базу, но намного реже.
Второй вариант — запоминать дату фотки, за которую пользователь голосовал в последний раз и в выдаче дальше выдавать ему только самые новые фотки. Тогда и выборка из базу станет проще намного и в таблицу голосов лазить не надо.
Третий вариант — это держать очередь «супер-новых» фоток, и отдавать пользователям фотки из этого списка. Такой вариант должен сработать, если у вас достаточно хорошая текучка фоток.
Доля истины есть. Только в итоге это вредит понимаю кода. А скорость, которую вы получите можно спокойно компенсировать включением кеша или какой-нить небольшой оптимизацией в коде.
Запрос сам по себе медленный. Вы только представьте, вы из всей таблицы фоток пытаетесь выбрать фотки, за которые пользователь не голосовал =)
Мне в голову не приходит, зачем это надо. Он в любом случае будет медленным.
В реальности ситуация как мне кажется может быть такой:
1. Это виджет в котором показывается рандомная фотка, за которую пользователь может проголосовать. Тут все просто выбираем 10-20-30 фоток за которые пользователь мог бы проголосовать и для каждой смотрим, было ли голосование или нет. Если было, то не показываем.
2. Если пользователь смотрит альбом фоток, то соответственно то же самое, смотрим за какие фотки пользователь голосовал, а за какие нет.
В любом случае у вас всегда должно быть какое-то ограничение на список выбираемых фоток.
Также не забывайте, что из мемкеша много вытаскивать ключи не по одному, а сразу списком, что ускоряет работу с ним.
Выбирается 20 комментариев, дальше для каждого комментария выбирается пользователь из кеша (а если нет в кеше, то делается SQL запрос и кладется в кеш).
Идея в том, что информация о пользователе выбирается не только на странице комментариев, но и на других страницах сайта, а значит скорее всего уже лежит в кеше и выбирать юзеров можно очень быстро.
Тут главное не упустить момент между «ну еще рано, у нас нет столько народу» и "***** мы лежим" =). Вообще оптимизацией надо заниматься тогда, когда сайт перестает справляться с нагрузкой и прооптимизировать быстрее, чем вводить новые сервера.
Во-первых не все проходят этап собеседования. Во-вторых некоторые направления развиваются очень быстро и закрыть все руководящие вакансии только внутренними переходами не получается. Мне кажется, что текучка на руководящих должностях очень низкая.
Если такое направление интересно -- можно подробно описать.
Действительно, если вы правильно настраиваете боевые сервера, то проблем у вас не будет, но к сожалению зачастую это не так.
Данным постом я хотел предупредить разработчиков о возможной проблеме, а никак начинать холивар.
Где-то в комментах была ссылка на этот пост: www.amiro.ru/blog/tech/how-was-php6-died
Сейчас такая возможность реализуется через указание charset_table. Есть ли какие-нибудь более «правильные» способы для этого?
Из вариантов оптимизации могу лишь предложить перед входом пользователя сразу подготавливать ему очередь фоток из 10-20-30, за которые он не голосовал и потом их постепенно ему отдавать. Сколько фоток за сессию отмечает пользователь вы из своей статистики должны знать. Такой вариант будет грузить базу, но намного реже.
Второй вариант — запоминать дату фотки, за которую пользователь голосовал в последний раз и в выдаче дальше выдавать ему только самые новые фотки. Тогда и выборка из базу станет проще намного и в таблицу голосов лазить не надо.
Третий вариант — это держать очередь «супер-новых» фоток, и отдавать пользователям фотки из этого списка. Такой вариант должен сработать, если у вас достаточно хорошая текучка фоток.
Мне в голову не приходит, зачем это надо. Он в любом случае будет медленным.
В реальности ситуация как мне кажется может быть такой:
1. Это виджет в котором показывается рандомная фотка, за которую пользователь может проголосовать. Тут все просто выбираем 10-20-30 фоток за которые пользователь мог бы проголосовать и для каждой смотрим, было ли голосование или нет. Если было, то не показываем.
2. Если пользователь смотрит альбом фоток, то соответственно то же самое, смотрим за какие фотки пользователь голосовал, а за какие нет.
В любом случае у вас всегда должно быть какое-то ограничение на список выбираемых фоток.
Также не забывайте, что из мемкеша много вытаскивать ключи не по одному, а сразу списком, что ускоряет работу с ним.
Идея в том, что информация о пользователе выбирается не только на странице комментариев, но и на других страницах сайта, а значит скорее всего уже лежит в кеше и выбирать юзеров можно очень быстро.