Jump to content
Torsten Baldes

Processwire and "Time to first byte"

Recommended Posts

Hi,

i noticed on my sites and also on other processwire sites, that the time to the first byte is quite long (> 500ms).

Is there a way to speed up this waiting time, without using plugins like ProCache?

i benchmarked some sites from the showcase and from Processwire weekly and nearly all of them perform bad at First Byte Time.

is this related to Processwire or just standard behaviour for php/cms sites?

Here are the tests:

First Byte Time - Grade F

URL: http://c-logistic.de/

Test: http://www.webpagetest.org/result/150601_J7_3992e9491b6acf72f73f10441880e6a2/

URL: http://von-bergh.de/

 

URL: http://www.orkork.de/

 

URL: http://www.dojofuckingyeah.de/

 

URL: http://www.schloss-marienburg.de/

 
 
First Byte Time - Grade C
 

URL: http://www.grupoolmos.com/

 

URL: http://www.pipistrello.ch/

 
  • Like 2

Share this post


Link to post
Share on other sites

The answer is quite simple.

flush();
ob_flush();

Use these as soon as you have parts of "final" markup, that you can send to the user. Sadly this needs to be in order, so most of the time it's more like:

"header" - flush - "content" - flush - "footer" - end

This speeds up every request.

Other options are caching and faster servers (and/or cdn). It doesn't necessarily need ProCache for fast caching. TemplateCache and MarkupCache are quite powerful, too, but they do require php to run (fast servers *hint*).

Share this post


Link to post
Share on other sites

Sites with A (and B) grade are almost certainly using ProCache. In real life it is really hard to get A grade without ProCache. And yes, some CMS/CMF are faster. The best results are achieved with SSD (for data and for mysql data), tested myself, almost double the speed...

Share this post


Link to post
Share on other sites

The site is currently hosted on an utterly lazy shared webspace. Guess that alone makes a huge difference ;)

Also, caching is currently completely deactivated - and I have no senseful reason for that, mark it as "testing" ;) I'll activate it in the near future

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By muzzer
      Existing PW site version 2.7.2 core running on php7.1. Site is perhaps 7 yrs old and never misses a beat. Can't speak highly enough about this solid version, but....
      As new php versions are released (v8 in the next year I think?) and each seems to get quicker I'm looking at upgrading to php7.3 or 7.4 and upgrading the site to PW v3.x.
      I've been away from the forums since v3 was released so don't know much about it. I guess it's stable as it's been around for ages now, but what I'm wondering is:
      what are the real advantages of upgrading to v3 for a site which is actively used but with only periodic development. And what are the disadvantages if any? Is there any speed impact (good or bad) in either general site speed under 3.x or admin-use speed/ease of use? any issues with either PW version with newer php versions (>7.1) I should know about? is there any good write-ups/vids about new features etc of v3 compared to v2.7? Thank you
       
    • By LuisM
      Hi there,
      while developing a sideproject which is completly build with ProcessModules i suddenly had the urge to measure the performance of some modules 😉 as a result, say welcome to the FlowtiAppPerformance module. 
      It comes bundled with a small helper module called FlowtiModuleProfiler. In the first release, even though you could select other modules, it will track the execution of selected Site/ProcessModules. 
      This will give you the ability to gain insights how your Application behaves. 
      The Main Module itself will come with 2 Logging Options, Database or PW Logs. Select Database for Charts and Logs...well If you just want your profiles as a simple log file in PW. 
      You also could choose to dump the request profile into TracyDebugger as shown here:

      Dont wonder about my avg_sysload, somehow my laptop cant handle multiple VMs that good 😄
      Settings Screen

      Monitoring

      FlowtiLogs

      again, dont look at the sysload 😄
      I will update the Module in the future to give some filter options and aggregation, but for now it satisfies my needs. 
      I hope it is helpfull for some. 
      Module is submited to the directory and hosted at github
      https://github.com/Luis85/FlowtiAppPerformance
      Any suggestions, wishes etc. are much appreciated. 
       
      Cheers,
      Luis
    • By Peter Knight
      Is there a way to make JPGs progressive by default via the API?
      I've added the following to my site/config.php file but user-uploaded images are often displayed as non progressive.
      $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'interlace' => true, // use interlaced JPEGs by default? (recommended) 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 95, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 0.5, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) ); Thanks
    • By Mobiletrooper
      Hey Ryan, hey friends,
      we, Mobile Trooper a digital agency based in Germany, use ProcessWire for an Enterprise-grade Intranet publishing portal which is under heavy development for over 3 years now. Over the years not only the user base grew but also the platform in general. We introduced lots and lots of features thanks to ProcessWire's absurd flexibility. We came along many CMS (or CMFs for that matter) that don't even come close to ProcessWire. Closest we came across was Locomotive (Rails-based) and Pimcore (PHP based).
      So this is not your typical ProcessWire installation in terms of size.
      Currently we count:
      140 Templates (Some have 1 page, some have >6000 pages)
      313 Fields
      ~ 15k Users (For an intranet portal? That's heavy.)
      ~ 195 431 Pages (At least that's the current AUTOINCREMENT)
       
      I think we came to a point where ProcessWire isn't as scalable anymore as it used to be. Our latest research measured over 20 seconds of load time (the time PHP spent scambling the HTML together). That's unacceptable unfortunately. We've implemented common performance strategies like:
      We're running on fat machines (DB server has 32 gigs RAM, Prod Web server has 32gigs as well. Both are running on quadcores (xeons) hosted by Azure.
      We have load balancing in place, but still, a single server needs up to 20 sec to respond to a single request averaging at around about 12 sec.
      In our research we came across pages that sent over 1000 SQL queries with lots of JOINs. This is obviously needed because of PWs architecture (a field a table) but does this slow mySQL down much? For the start page we need to get somewhere around 60-80 pages, each page needs to be queried for ~12 fields to be displayed correctly, is this too much? There are many different fields involved like multiple Page-fields which hold tags, categories etc.
      We installed Profiler Pro but it does not seem to show us the real bottleneck, it just says that everything is kinda slow and sums up to the grand total we mentioned above.
      ProCache does not help us because every user is seeing something different, so we can cache some fragments but they usually measure at around 10ms. We can't spend time optimising if we can't expect an affordable benefit. Therefore we opted against ProCache and used our own module which generates these cache fragments lazily. 
      That speeds up the whole page rendering to ~7 sec, this is acceptable compared to 20sec but still ridiculously long.
      Our page consists of mainly dynamic parts changing every 2-5 minutes. It's different across multiple users based on their location, language and other preferences.
      We also have about 120 people working on the processwire backend the whole day concurrently.
       
      What do you guys think?
      Here are my questions, hopefully we can collect these in a wiki or something because I'm sure more and more people will hit that break sooner than they hoped they would:
       
      - Should we opt for optimising the database? Since >2k per request is a lot even for a mysql server, webserver cpu is basically idling at that time.
      - Do you think at this point it makes sense to use ProcessWire as a simple REST API?
      - In your experience, what fieldtypes are expensive? Page? RepeaterMatrix?
      - Ryan, what do you consider as the primary bottleneck of processwire?
      - Is the amount of fields too much? Would it be better if we would try to reuse fields as much as possible?
      - Is there an option to hook onto ProcessWires SQL builder? So we can write custom SQL for some selectors?
       
      Thanks and lots of wishes,
      Pascal from Mobile Trooper
       
       
×
×
  • Create New...