Я так понял - их причину выяснили: скрипты выдают кривые заголовки content-length.
Ему посоветовали также протестировать siege реальную нагрузку.
Тогда не трогать - и дать сделать все людям умеющим.
Могу и сделал. Это вы полезли "опытом" меряться.
Вы телепат и знаете что я думаю? Нет там никакого второго и первого - проблема одна и та же: изменение большого объема информации *в кеше* при достаточно интенсивной записи.
И что же пишется?
Ну, "кеш" ТС меня тоже насторожил. И некоторые другие моменты.
Правильно (хотя я бы выбрал "полезны"). Но ключевое слово: "могут".
Т.е. в принципе, вы понимаете что это не буквальное руководство к действию для дебилов, реагирующих на упоминание в тексте числительных. Именно то, о чем написал я: не трогай, не померив.
В абзаце ровно одна мысль, как и положено абзацу. Упоминание о локах - попутное, "вдобавок". Эта проблема явно связана с тем, что там обсуждается, начиная с первого предложения (The issue here was that ...). Уберите активное письмо - уйдут и локи.
Вот когда вы научитесь цитировать *все*, а не только вырванные с мясом куски, что-то для вас "подтверждающие" - дальнейший разговор будет иметь смысл.
Как раз напротив. Переведите, пожалуйста:
Вы снова подсократили "перевод". Кстати, как и предыдущую цитату:
О гуру, выделите в этом абзаце ключевое предложение. И сравните затем с тем что процитировали вы.
Я о комментарии упомянул еще и потому, что много воды утекло - часть проблем исправлена. Не случайно боец в вашем примере наткнулся на проблему при обновлении.
Не нравится - не еште.
Там достаточно сложно однозначно сказать в чем причина. Людям, которые не смотрят вам в рот - может быть заметно.
Проблема, думаю, опять-таки не в "высокооконкурентной" нагрузке - а буквально в том, что описано в документации и блоге оракла.
Что характерно, проблема появилась при обновлении версии mysql. Может буратин тот, кто это сделал?
Комментарии посмотри. Самый первый как раз про это. Для справки: в Debian stable сейчас 5.1.49.
Последний раз напомню:
Уменьшать с 200Mb до 60Mb - в данном случае замена шило на мыло. Абсолютно бессмысленная без измерений и последующего анализа.
Смоделируйте реальную нагрузку. Убедитесь, что ваш "кеш" при этом задействован.
Что непонятно?
И что, это разве не проблема? В сухом итоге: проблема есть, но источник ее определить не сумели.
Может ТЗ был принят безграмотный (сделай то, не знаю что), а может доверили выполнение нанятому школьнику. Извините, но в любом случае двоечка.
Явное противоречие. Почему именно вы думаете, что "установка происходит успешно"?
Только если эти 2Gb будут действительно использоваться.
Во-вторых, не передергивайте, пожалуйста. Я только упомянул, что никакого смысла в изменении размера кеша у ТС - не вижу. Ну разве ради "когда коту делать нечего..."
Боюсь, в магию я тоже не верю. Нужно разбираться и анализировать конкретную конфигурацию. Может дело было именно в баге. Или (более вероятно) в том, что я привел по ссылке выше (дело там не в низкоконкурентной нагрузке).
Не ткнете более конкретно? Что-то не вижу его "ссылки".
Все остальное по вашей ссылке - бездоказательно, увы.
В документации ничего не написано про "высокооконкурентную" нагрузку. Там как раз именно то, что я привел из блога оракла:
*might not be* - вам перевести?
Учитывая тенденцию "велосипедистов" быть, мягко говоря, малоквалифицированными программистами - пока не исключаю здесь проблемы. Например, что будет если запросов пришло несколько, а файла кеша еще нет?
Отличите между *чем* и *чем*. Тем что скрипт пишет в заголовке и реальным размером вывода. Тогда это проблема. Учитывая что такая порнография у вас в 20% запросов - стоило бы исправить.
И что?
Таки не осилил ман? Нет никакой реальной проблемы воспроизвести посещаемость по статистике LI. Лучше, конечно, использовать siege - раз о нем слышали...
