7

Я разработчик веб-приложений, использующих свой ноутбук в качестве автономной среды разработки (стек WAMP). Я только что перешел с 32-разрядного ноутбука Core2-duo Vista с 2 ГБ ОЗУ и жестким диском SATA на 64-разрядный i5-2520M Win7 с 4 ГБ ОЗУ и 128 ГБ SDD (Corsair P3 128).

Мой первоначальный опыт был тем, что я ожидал, быстрой загрузкой, быстрой загрузкой всех приложений (Eclipse теперь занимает 5 секунд, а не 30 с на моем старом ноутбуке), в целом отличный опыт. Затем я начал собирать свой стек разработки, как LAMP (используя VirtualBox с гостевой системой Debian) и WAMP (Windows native apache + mysql + php). Я хотел сравнить эти два.

Это все еще отлично сработало, затем я начал тянуть свои проекты в эти стеки. И тут наступил неприятный сюрприз, один из этих проектов показал намного худшее время отклика, чем на моем старом ноутбуке (это было верно как для стека VirtualBox, так и для стека WAMP). Конфигурации Apache, php и mysql были практически идентичны во всех средах. Я начал делать много тестов и профилирования, и вот что я нашел:

  1. Все общие тесты производительности (Performance Test 7.0, HDTune Pro, wPrime2 и некоторые другие) дали большое преимущество новому ноутбуку. Ничего удивительного здесь. Специфичные для диска тесты показали, что операции чтения / записи достигли максимума около 380M / 160M для SSD, и все операции с блоком разных размеров также работали очень хорошо.

  2. Начался сравнительный анализ производительности Apache с Apache Benchmark для небольшого статического HTML-файла (10 одновременных потоков, 500 итераций).

    • Старая тетрадь: минимум 47 мс, медиана 111 мс, макс 156 мс
    • Новый стек WAMP: минимум 71мс, медиана 135мс, максимум 296мс
    • Новый стек LAMP (в VirtualBox): минимум 6 мс, медиана 46 мс, максимум 175 мс

    Прямо здесь я не понимаю, почему собственный стек WAMP работал так плохо, но, по крайней мере, среда LAMP принесла ожидаемую скорость.

  3. Измерение производительности Apache для не кэшированного php-контента. Php запускает цикл 1000 и генерирует sha1 (uniqid ()) inisde. Опять же, 10 параллельных потоков, 500 итераций были использованы для теста.

    • Старая тетрадь: мин 0 мс, медиана 39 мс, макс 218 мс
    • Новый стек WAMP: минимум 20 мс, медиана 61 мс, максимум 186 мс
    • Новый стек LAMP (в VirtualBox): мин. 124 мс, медиана 704 мс, макс 2463 мс

    Что за черт? Новый LAMP работал ужасно, и даже новый родной WAMP был лучше, чем старый ноутбук.

  4. тест php + mysql. Тест состоит из подключения к базе данных и чтения одной записи из таблицы с помощью INNER JOIN еще на 3 (проиндексированных) таблицах, повторяемых 100 раз в цикле. Базы данных были идентичны. 10 параллельных потоков, 100 итераций были использованы для теста.

    • Старая тетрадь: минимум 1201мс, медиана 1734мс, максимум 3728мс
    • Новый стек WAMP: минимум 367мс, медиана 675мс, максимум 1893мс
    • Новый стек LAMP (в VirtualBox): минимум 1410мс, медиана 3659мс, максимум 5045мс

    И тот же тест с параллелизмом, установленным в 1 (вместо 10):

    • Старая тетрадь: минимум 1201мс, медиана 1261мс, максимум 1357мс
    • Новый стек WAMP: минимум 399мс, медиана 483мс, максимум 539мс
    • Новый стек LAMP (в VirtualBox): минимум 285 мс, медиана 348 мс, максимум 444 мс

    Строго для моих целей, так как я использую автономную среду разработки (= низкий уровень параллелизма), я могу быть удовлетворен результатом второго теста. Хотя я понятия не имею, почему среда VirtualBox работала так плохо с высоким параллелизмом.

  5. Наконец я выполнил тест на включение многих файлов php. Приложение, которое я упомянул в начале, которое так плохо работало, имеет тяжелый загрузчик, загружает сотни небольших библиотек и файлов конфигурации во время инициализации. Таким образом, этот тест ничего не делает, просто включает в себя около 100 файлов. Параллельность установлена на 1, 100 итераций:

    • Старая тетрадь: мин 140 мс, медиана 168 мс, макс 406 мс
    • Новый стек WAMP: минимум 434мс, медиана 488мс, максимум 604мс
    • Новый стек LAMP (в VirtualBox): мин 413 мс, медиана 1040 мс, макс 1921 мс

    Даже если я считаю, что VirtualBox достиг этих файлов через общие папки, и это немного замедляет работу, я все еще не понимаю, как старый ноутбук так сильно выигрывает у обеих новых конфигураций. И я думаю, что это истинный корень низкой производительности, так как приложение использует еще больше включений, и весь начальный запуск будет происходить несколько раз в запросе страницы (например, для каждого вызова ajax).

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

    Как вы думаете, почему я испытываю такие низкие показатели производительности? Какие есть варианты исправить эту ситуацию?

РЕДАКТИРОВАТЬ: кажется, что я, наконец, нашел корень проблемы, по-видимому, SSD могут страдать от снижения производительности при использовании в ноутбуках с чипсетами Intel HM55 или PM55. Пожалуйста, смотрите мой полный ответ ниже.

2 ответа2

2

Другими словами, тесты уровня диска дают выдающиеся результаты вашему SSD, в то время как при практическом использовании диск адски медленен. Так что что-то замедляет работу, делая доступ к файлам намного медленнее, чем ожидалось.

Там может быть несколько причин:

  • Наиболее вероятное: есть антивирус. Некоторые из них действительно убийцы тестов, и вы вряд ли можете предсказать, как они влияют на производительность без тестирования.

  • Что-то другое замедляет доступ к файлу. Каждый раз, когда вы, кажется, тестируете множество операций с небольшими объемами данных. Но каковы показатели при чтении или записи файла размером 10 ГБ?

  • Конфигурация, связанная с ОС, может отличаться. Например, ОС использует кэш для небольших файлов на компьютере с жестким диском, но не на компьютере с твердотельным накопителем. В этом случае тесты неверны для первой машины, так как вы на самом деле не проверяете скорость жесткого диска.

  • Дисковая конфигурация может отличаться. Такие параметры, как политика кэширования записи (в Windows), могут влиять на производительность.

  • SSD может работать неправильно.

1

После долгой недели борьбы с настройками для лучшей производительности, я наконец нашел несколько настроек, которые дали ожидаемые результаты. (Это ноутбук Fujitsu LIFEBOOK S751 с чипсетом Intel HM65 и BIOS на основе ноутбука Phoenix TrustedCore)

В BIOS в разделе «Дополнительные / Прочие настройки» раздела «Управление аппаратным питанием» было два варианта конфигурации:

  • Энергосбережение процессора в режиме ожидания (AC)
  • Энергосбережение процессора в режиме ожидания (батарея)

Первый был настроен на "Энергосбережение", второй - на "Длительный срок службы батареи". Я установил и на нормальный, и вот, я получил на порядок лучшие времена ответа на все мои тесты.

Видимо, другие тоже столкнулись с этой проблемой:http://forum.notebookreview.com/solid-state-drives-ssds-flash-storage/513313-laptops-w-intel-series-5-chipset-can-not- берите полное преимущество быстрой перемотки ssds.html

Цитирование из этой темы:

Согласно результатам тестов, проведенных несколькими участниками, ноутбуки с процессорами Intel HM55 и PM55 не могут в полной мере использовать преимущества быстрых твердотельных накопителей. Эти чипсеты очень распространены в современных ноутбуках. Падение производительности особенно заметно в 4K произвольном чтении и записи. Проблемы, кажется, вызваны агрессивной реализацией функций энергосбережения ...

Конечно, теперь вентилятор продолжает вращаться каждые 5 секунд или около того, что довольно раздражает, но, по крайней мере, я могу выполнять свою работу.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .