So, welcome to this talk about PHP Upcache, real podcast and preloading. So we will be talking today about how we can tune our PHP installation and we will do that by tuning PHP settings. So new PHP versions always get faster, but we can make them go even faster just by changing the things that we get for free. So if we take a new version, they figure out some way of doing memory management a bit better. So we get faster PHP versions. We saw that from 5 to 7. And then we, a minor version, since 7, got a little bit faster. So we have that straight out of the box, but we can also improve it even more just by fine-tuning the settings of these new features. So first some groundwork. Who doesn't know PHP? There's one. Okay. So PHP is a scripting language, as you will know. And basically it's a fire and forget language. So this means that we don't have any manual compilation step. So every time we type something, we go to a browser, we hit reload. Everything is getting compiled on the fly and we see our new output. So this is the groundwork we all are familiar with what PHP is. And then the second concept for setting the stage is PHP FPM. So who isn't using PHP FPM? I think, yeah, few hands, but almost everybody is using FPM. It's the only relevant SAPI nowadays. So what is FPM? We have a from-end web server, like Apache or Nginx, and if we have a PHP file that has to be executed, we forward that request to the FPM. So for instance, we have a master process listening on port 9,000, and every time a request comes in, the master process starts or looks if there are any trial processes available. And then creates one or just forwards it to the running trial process. So just to keep in mind for the rest of the presentation, we have shared memory, and shared memory is located in the master process. So if you have trial processes, the shared memory is located in the master process. So this is really the concept of this shared memory. So here we have an example of the master process that's always running, and every time somebody goes to our website, we have a trial process running. In the rare occasion that I have multiple visitors on my site, I have more processes. So yeah, you get the concept. So now this shared memory. What is this shared memory? So in computer hardware, shared memory refers to the block of random access memory that can be accessed by several different central processing units in a multi-processed computer system. So what this means is every process has its own batch of memory, and the shared memory is shared over those processes. So if we want to save something and share it between the different processes, we use a shared memory. So this is the groundwork for the rest of the presentation. So all set, okay. My name is Joachim Kudanis. I'm a father. I started running like now a year and enjoying that very much, but more relevant to this presentation is I'm the co-organizer of a local user group in Belgium. I'm a coach at our local coded dojo, where we teach kids how to program and how to interact with cool little robots and stuff. And I'm a developer at Combell, a web hosting company in Belgium. So this talk is about performance, right? Yeah, you're right. This is all about performance. But why did I create this presentation? It's because at Combell, I'm part of the performance team. So that's a special team which analyzes problematic websites from customers. We do a deep dive in the code of the customer. And we also have the knowledge of how our systems, how our backend systems are set up. So we really know where to look and where to spot issues. So here we have the quote, 80% of the performance issues have nothing to do with your server. So we really dive into, as a hosting company, we want to sell more servers. But sometimes we really have to optimize the code itself. And a lot of that optimization is just by knowing how everything works under the hood and knowing where we can tune settings, but also how you write specific code. So this is an example, a pretty famous gist where we have an overview of the different latency numbers. So at the top, we have the L1 and L2 caching from the CPU. And you see that every time we go a step further. So if we want to read stuff from memory, we are a bit slower. If we want to read a megabyte from the hard drive, we are again a bit slower. If you want to add a round trip to a different data center, everything gets slower. So we want to keep everything as close to the CPU as possible. So this is more a graphical visualization of that. So now that we know all the things that we want to change, how can we actually fix it? And we see a lot of problems with disk IO. And disk IO, if you have a look at the Linux storage stack, at the top there you have our little application. And every time we want to access the disks, we go to the virtual file system. And there we have the block-based file systems that we know, so the local storage. But at a hosting company, we use the network file system a lot because that's easier just to scale, do backups. But the problem there is we're not only doing the file system lookup, but we also have to do a round trip to the network. So if you slide this a bit up, you come at the block layer and then the block layer will talk to the physical drives. But in our setup, we use NFS, so the network file system. And the network file system has an extra, we have all the advantages of using the NFS. But we have a new set of problems because instead of going from our user program to the file system through the VFS, we have to go through the network and then do again look at the file system at the NFS server and then take all the file information. So a lot of the things that we can optimize are located in that and stopping that overhead of going over the wire. So we have, if you're familiar with NFS, you have NFS cache, which caches a lot of information on the client. But if we're using PHP, we want to have highly dynamic, we want to program with PHP, we want to change our files. So we still occasionally have to travel that network layer. So now that I showed you all the theoretical information, how can we actually tackle all these challenges in PHP? And as the talk title suggested, we have three topics that we use to tackle all these problems. We have the real podcast, the opcache, and then preloading. So let's dive into the real podcast. So what the real podcast is, it is a system in PHP and it is used to reduce IO. So we want to eliminate the IO coming to the file system as much as possible. And it does that by caching all possible pods to a specific destination pod. So if we use Composer, we have a lot of files that we want to load, and in our application, we do a lot of relative pods, like .slash, and then we go to a pod. Instead of always calculating all those, where that specific file is living, it will explode, kind of explode on the pod, the complete pod, and store every segment in a real podcast so that it doesn't have to go to the file system every time it needs to find out where something is located. So remember the shared memory I talked about. The shared memory is located in the parent process and the master process, but real podcast is not stored in shared memory. It's stored in the process memory. So this means that every time a child starts, it has to rebuild the whole real podcast, which isn't that bad, but if you see a lot of problems with cold starts of the process, you just want to have at least one process always running so the real podcast isn't cleared. So by default, we have four megabytes for that real podcast to store, but again, it's not stored in shared memory, so you have to watch out if you have, like, 200 child processes, you have four megabytes, five is 200, so you have to watch out that you don't run out of memory. So before PHP 7, the default was 16K and we all know that all the frameworks that we use, that's way too low, so the new default is four megabytes. And as I mentioned before, this helps a lot with the NFS problem that we have. So try to keep as much processes running to avoid the overhead. So we have a couple of functions that we can use. We have the real pod cache kit, which just gives you a list of all the files that are in the real podcast. And we have the cache size, which just shows you the configured, the currently configured size. There's also a real pod function, but this has nothing to do with real pod caching. It uses real pod caching under the hood, but it just calculates the actual destination pods of a specific relative pod. So a small demo. I have this file, which I try to access three files on disk. So I have a relative one, the ffr.php, then I have an absolute one, and then again another example of file loading. So if I open the real pod cache kit, I first of all get my current working directory. So I have my home directory. And then you can see that it stores all the upper pods. So when another script is accessing something differently, most of the information is already there. So if we scroll down, we see that we have the relative pod to the ffi, which maps to the absolute pod. And then again, we have the absolute pod, which maps everything. So you can see that if you have a framework, if you have a lot of files, this can get quick quite quickly. But this helps a lot with performance. So real pod cache, simple concept. There's a couple of things you can see. We have some in-eye settings. So we have the size, which is four megabyte. We have the time to live. So time to live on a server, just put it really high. It's not really that important. If you're in development and you want to benefit from it, put it a bit lower, it's just a small time to live. OK, so real pod cache, not that exciting. Just keep in mind that it's there, and you want to keep the master and job processes in check. So next up is opcache. Who's not using opcache? Nobody. That means everybody is on a recent PHP version, because opcache was just added by default. And what is opcache, it improves PHP performance by storing pre-compiled script, bytecode, and shared memory, thereby removing the need for PHP to load and parse scripts on each request. So a basic PHP request looks like this. We have the PHP code, and we want to execute that code. And first of all, we have a lexer and a parser, which creates tokens. And that's token. Those tokens are then available as an abstract syntax tree. And then we can use those tokens in a compiler. The compiler will generate upcodes, and those upcodes will go into a specific VM for a specific operating system, and then will be executed to produce the results. So as I mentioned before, PHP is a fire and forget. It's a throwaway language. So it always performs these steps. It reads the PHP code, it lexes, it creates tokens, then it compiles it and generates upcodes, and then it executes those upcodes. And once that's done, the request that's served, all the information is discarded, everything is thrown away. So every request, we have to do that over and over again. So if we have a look, we have the abstract syntax tree. And then the next step is the upcodes. But what are upcodes? So in computing, an operation code is the portion of a machine language instruction that specifies the operation to be performed. So what does it mean in the context of PHP? If you want to have a look at what upcodes that are available and what upcodes that are being used in PHP, you can go to evol.org, where you can run a lot of PHP script, and then run them over all the versions that are available. But there's also a little tab called a VLD. And that's sourced for the Vulkan logic dumper. And the Vulkan logic dumper generates a list of all the things that your little script is doing and shows you all the upcodes that are being generated. So here you can see that we have an echo, that we have a jump if something, if the false is being true, false or false, then you go to the next branch.  So again, as you can imagine, this can get big fairly quickly if you're using libraries or frameworks. So this is just the small script, which is to show you all the upcodes, but this can get gigantic if you have a lot of files and codes. And most of the time, the upcodes don't change. First of all, if you're using Composer and you have a vendor directory, all the files in that vendor directory are not changing. And if you are running a specific version of your application in production, you're not, hopefully, live editing files in production, so those upcodes, they don't change. So when things don't change, what do we do? We just add some cache in it. And here is where OpCache comes into play. And OpCache comes from a long history of OpCode caches. So before, we had OpCache as part of the PHP engine. We had APC. We had MMCache. We had the Zend Optimizer.  But as of version 5.5, Zend donated the Zend Optimizer to the PHP source. And Zend Optimizer came from Zend Guard, which was or still is a tool to encode your PHP files and then distribute to them. But they took out that Optimizer part and just put it into PHP. So this whole step, this whole parsing and then compiling and then executing, if we add to the cache, we just eliminate the first part of it. So all those OpCache, all those OpCodes are cached into the shared memory. So they're, in the case of the FPM, all stored in the master process. So part of the OpCache was because it stems from Zend Optimizer, part of the OpCache Optimizer, part of the OpCache, sorry, is the OpCache Optimizer. And that's a specific part of OpCache, which gets better every time there's a new release. And what it does, it optimizes branches. It optimizes that code. So if it sees that there are some lines below a return, it will detect that and just throw away the OpCodes instead of storing OpCodes that aren't actually doing anything. And also, small things like this notation, if you don't do this already with a static analyzer, the Optimizer will just do it under the hood and save the better way of doing it in the OpCache. So if we have a look at how that actually results, so what you see here is we have the if false. So the first part is never executed. So all the parts of the condition, I just not needed there. So what the OpCache Optimizer will do is just echo true and then assign something and then echo again and return. So you can see that this reduces the OpCodes in this example by half. But if you have a lot of PHP files, this will reduce all the OpCodes drastically. So now that we know what the OpCaches are, what functions do we have? So we have some functions to gather some information. So we have the get configuration, which just all the settings that are being used. We have the OpCache get status, which is the most important one to get all the information from. I have an example later on. Then you can pass a specific file to the cache to see if it's stored in the OpCache. And then we have some specific functions to take action. So there's a function compile file where we can manually take this file and store all the OpCaches, so calculate the OpCodes, and store them into OpCache. We can invalidate specific files. So this is handy if you're doing a release, a deploy, and you want to invalidate specific files so that the new OpCodes are getting stored. And there's also the OpCache reset, where it's just resetting the complete OpCache, so all the files that are cached are being destroyed. So again, small demo. I have a small script, which just does a printr of OpCache get status. And what that gets us is a nice overview of everything that's happening with OpCache. So we can see that OpCache is enabled. The cache is not full. We have no restart coming up. And then the most important part, the memory usage. You can see if it's full or if the OpCache is nearly full. We have the wasted memory marker, more than that later. Then we have the intern strings. That's also a trick to get our OpCodes a bit smaller, also more on that later. And then the most important part is the OpCache statistics. So here you can see that we have only one script because we're executing it from the command line. We only have one script that's being cached. We have a number of, we have no hits because this is the first time that we execute this. And then we have some restarts. So also again, more on that later. And we have no hits and one miss because this is the first time that we execute it. And if we do it on a command line, if we execute it again, we again will not have a hit because there's no shared memory. And a very important one, if you execute this on your web server, you will see here the OpCache hit rate. And now it's zero. But if you are running a production, you really want a OpCache hit rate of 99.99 because the moment it drops, this means you have changing files. That means you're not having a very optimized way of running OpCache. And then if you ask to include all the scripts that are being in the OpCache, you get a list of all the keys and then some statistics about the specific files. So I talked about the entourage strings. And this is something that's being used in a lot of languages. It's available in PHP since 5.4. And it's some kind of compression for source code. So if you have a lot of the same OpCache combinations that are occurring a lot, you can just compress that so that you have an even smaller footprint in the memory of all the OpCodes. And the entourage strings block is a part of the complete memory block that you reserve for the OpCache. So if this block is full, you will just use more memory than is needed. But again, that's also stored in the shared memory of the master. You see the keys thing a lot in the statistics. And this is just the full part and all the different relative parts, again, to a specific file. So if we go back here, these are just all the keys. This specific file has been compiled into OpCache and is accessible through that key. The next thing that we saw in the statistics output was the wasted memory. So by default, OpCache doesn't do any defragmentation. So OpCache was built for performance. So let's say we don't have anything in OpCache and we start PHP. We have two files and we put it in OpCache. And then PHP sees that the file has been modified. So instead of replacing the OpCache in memory for that previous entry, it just marks that previous entry as wasted and then adds the new compiled file at the end of the memory. And that's just done so that it doesn't lose computation over for cleaning up that memory. But if you have a lot of changing files, you have a lot of memory that's being marked as wasted. And sometimes you have a lot of files that are being invalidated. And if you have a lot of wasted memory, instead of cleaning up that memory, OpCache just resets itself. So it does a restart. So we're getting started from a clean slate and everything is filling up again. So yeah, if files change, they cause recompilation. And we have a couple of scenarios where the OpCache is restarting. So if we have a lot of wasted memory, so first of all, if the OpCache is full and we don't have any wasted memory, then the OpCache will just be full. It won't do a restart. It will just try to add some more files to the OpCache, but it will see it as full and it will just not add it to the OpCache. If we have a lot of changing files and we reach a specific percentage of wasted files, it will do an out-of-memory restart. So if you are monitoring your sites and you see a lot of old memory resets, it's just because you have a lot of changing files and you want to do something about that. The hash restarts are just if you have too many files and you have a limit on the number of keys that you can store. If you have too many files that you want to store and the OpCache sees that there's no place anymore, it will also trigger a hash restart so that it can start again adding new files. Again, you don't want hash restarts. And then the last one is just the function I showed you before, the OpCache reset, and that are the manual restarts. So again, as a hoster, we're monitoring all these settings and there's an example of a WordPress plugin trying to do an upgrade and then doing an OpCache reset because there are new files, so they didn't reset. But we saw an upgrade that was failing constantly, so we saw the loop and we saw in our statistics that there were a lot of manual restarts and that's something you can have a manual restarts once a day if you deploy new code, or if you deploy more, but you can't if you have 300 restarts in five minutes, there's something going on. So I showed you the restarts. Don't ever have a full cache. So if you don't have any memory left and OpCache is trying to compile your code and store all those upcodes into the cache, you will actually have done more work than before because you will have done all the extra work. Then you want to check if you want to put it into the cache and then you have to discard the information. So you actually added a new step in a way, which makes it even slower, so never have a full cache. Whenever we see sites that are having problems, the first thing I do is I check the upcodes, I check the statistics, and 9 out of 10 is just a full cache and it's much better if we just double the amount of memory that's allocated to it. So this was the part of the OpCache itself and we have another concept because now we're storing everything into memory. But there's also something which is called OpCache file cache and instead of when the process starts, reading the PHP files from memory, compiling them and then storing them into the OpCache, we can store the opcodes into a file and then the moment PHP starts, it will just take those upcodes and then put them directly into OpCache. So this can help busy sites. For instance, if you do a reload and you have a lot of visitors and instead of doing everything, compiling on the fly when they arrive, you can just copy it over from the files directly into the OpCache memory. And it also helps with the CLI. So in the example, in the demo example before, it just starts, every time it starts the process, it has to read the PHP file from disk, compile it, store it into OpCache if you want to and then throw it away. And if we store it into files, the PHP, the console can just start it based from those OpCache files. And we only need to add one setting and that's just a user directory. So here we have the file cache, we want to store it in that folder and then some extra checks. But the important one is the first one. So if we run that on a command line, we first have to say enable CLI because by default, OpCache is not supported on the command line. And then add the file cache that we want to store and run everything. Again, it's the same file as before. And if we then have a look at the cache, we have a hash and then the complete three where we store the OpCache in a binary file. So yeah, that's another thing you can do with OpCache. There's a cool example in a PHP architect article where they also deep dive into the OpCodes and to the OpCache and they're trying to use the compile files as a way of distributing packages, of distributing PHP so that you have like pre-compiled PHP. It's a nice way of investigating OpCache. Don't use it in production or don't use it to distribute your PHP code. So now that we know what OpCache is and what all the possibilities are, what can we tune? So we have, like I said before, we have some disaster recovery scenarios. Is your memory full? Is the internal strings parts full? Is the key store full?  You want to double the memory. You want to give it some more. Internal strings space. But also, if you see a lot of restarts, dive into the codes, see why those things happen. Maybe they are generating new PHP files and that they on the fly, for instance, and that they have to load. OpCache will also give a lot of warnings if this happens because you will see that you won't have the hit rate that we want. So we have some configuration settings that we can fine-tune. So first of all, in the memory, we have the memory consumption and this is the block that OpCache will be dedicating for the process, for the FPM to be using. So I think by default it's 46 megabytes. It depends on the application if you need more, if you need less. Then part of that 46 megabytes will be the buffer to store the internal strings so that you can fine-tune too. And then the how many files that are actually being allowed to be saved. So this depends also on the U-limits of your Linux systems, of your Linux system. But yeah, just make sure all the files that you have fit into that max. And then for invalidation, we have a flag where we can say that we want to have OpCache validate the timestamps of the files that exist in cache. So for instance, we have a file, we are chasing the file, and if we say validate timestamps on, then every time before fetching the opcodes from the cache, it will do a stat to the file system and see if the modified time is newer than what's in cache. In development, this is great. You can even say the revalidate frequency. So every two seconds have a look if it's changed. In production, you could say that you only want to revalidate every 60 seconds, but that's also a bit strange because you know exactly when you're deploying. We mostly recommend to just say validate timestamps off because if you do a stat, if you use the NFS, you have to still do the complete network, go through the complete network layer just to see if the file was modified on the NFS server.  And you can also configure the threshold of the max-wasted memory. So I think by default it's 5%. So the moment that the opcache sees that 5% of the memory is being wasted, it will just do a restart. So yeah, to avoid having a lot of restarts, just put it smaller, but on the other hand, just make sure you don't have any wasted memory. Try to figure out why the wasted memory was there in the first place. So we get stats by using get status. And the get status is good for parsing it into something else and then have some visualizations. So there are a few projects where we have a single PHP file. So we can just take that PHP file, I put it in our directory, in our web server directory. And it will use all the information from the get status to show you how many memory you have, how many hits you have versus messages. So you have some more information. It's very important that this page is being served from the same FPM pool that you want to investigate because if you run get status on a command line, that's just the status from the command line and nothing to do with the FPM. So just make sure if you are monitoring that you monitor the correct process. So this is an example, you have another example where you can see the different restarts, where you can see the stats of the memory. So it's all based on the same information, it's just different views. So I mentioned the revalidation stuff and what you can do. So if we want to deploy a new version, we want to avoid that all the new customers, all the new visitors are trying to compile all those upcodes and then putting them all in the opcache. So we can do some kind of priming and we can do that by, for instance, we deploy a new version and then because we want to restart a specific or we want to invalidate a specific opcache from an FPM, we have to, for instance, do a web call, do a hidden script or a password protected script, which on this turn tries to modify the current opcache. So we have, for instance, we do a push, we know what files have been changed and have been deployed and then we can, for instance, get a list of all the changed files, push that to a hidden file and then ask the file to compile all the changed files. Most of the time, they just do a callback to a PHP file that's on the server, which on this turn just say FPM reset and everything is emptied. But if you have a busy site, you can use different FPM pools. So we have, like I showed before, we have a FPM master with different clients, with different channels and if we deploy a new version, we can create a new FPM pool, which we then prime a bit by going to some sites on that specific pool and the moment the new FPM pool has been primed, we can then point the Nginx or Apache, which it says in front, to the new port and we have a fully primed opcache. So we don't have any downtime, we don't have any spikes in visitors trying to cache all the opcodes. Or we can use preloading. So preloading is something new in PHP 7.4. So preloading preloads PHP functions and classes once and uses them in the context of any future request without overhead. So magic, everything. So it is basically opcache on steroids. So if we look at preloading, it is part of the opcache because it is just an optimized way of storing those opcaches. And what it basically does, if you start an FPM server and you have preloading configured, before accepting any requests, it will preload your application in a way that you wanted to be preloaded. So this loads the code into memory permanently. So we don't have any overhead of copying it from the shared memory to the process memory and then doing stuff with it. So if we compare it to opcache, in opcache we have opcodes stored on a file-based way. So we have file X. So we have the class animal and we store all those opcodes into the shared memory and then we have the subclass cat and then we store all those opcodes into memory. But every time that we want to use the cat class, we have to fetch those opcodes from the memory and then construct the complete object and glue all the classes together. So what preloading does, it helps with all those class libraries. So it helps with all the opcaches, opcodes that already being generated and then stores them in a specific way that we don't have any overhead. And what this basically does is it will, your own code will be as performance as the native PHP, the native PHP functions because it was just been stored into memory before accepting any requests. And it does that by a simple file with some loading magic. So the configuration here, we only have one configuration option and that's opcache.preload where we just specify the path to a specific file. And that file will be executed. So that's the only thing it will do. It will start FPM, it will see the opcache preload, it will execute that file. Once that file has been completely executed, it will start accepting requests. So what you want to do in that preloading file is just get a list of all the files that you want to preload and then run them through opcache.compile file so that they are stored in the opcache. And then just that script exits. And from that moment, all the things that you have been, that you loaded into the preload.php file will be available for all the future requests. So as I mentioned, we have the cat and the animal file. You have to make sure that you do that in the correct order because if some classes can't be constructed, they will just be discarded from the preloading and it won't be in memory so it will still have to load them every time. So preloading in the wild, we have two examples. We have a lot of example which they try to tackle the preloading problem. And in PHP, in symphony, since 404, so there's a blog post about it, since 404, they're already using the knowledge that they have in the dependency container to generate a file with classes that you probably want to preload because they know all the files that you want to use. So they use, you can't see it really well, so they have the var cache def and they have a .preload.php file and every time you compile the complete container, that file will be present since 404. So if you want to start using it, you just add that file to your preloading ini setting. So there are some things that you have to keep in mind. We have a .ini setting, so it's a complete server. So if you are doing multiple applications in a single server, this won't work because the preloading is for a complete installation. And you don't have any functions to reset the preloading, to reset the preloading memory. So because it is a file which is executed before we start accepting request, you have to do a full restart to empty the memory of the server. So you really have to keep that in mind. So when we talk about all the files that we use, composure knows what files we were using, right? So the moment that the preloading RFC and PHP was available, there was a preloading support RFC and composure where a lot of excitement, a lot of exciting people were, we know what files that we want to load because we are doing all the dependencies. But yeah, it's a bit tricky. Composure doesn't really, composure knows all the dependencies you want, but it doesn't really know what files you actually are using. So there were some benchmarks on this link and there were benchmarks doing executed without preloading, then preloading of the hot classes and the hot classes are just a trick where we get the status of all the files that are being in the opcache and only use those files because composure has a lot of files everywhere, but you're not using all those PHP files. So by doing this trick, you only take the files that are actually being used in the opcache. And then they also had a benchmark where they just took all the files and they did that by requiring the complete class map. So if you have a look at the results, so only the hot files, we have like 900 ish and if you do all the files that are available in composure, you have almost 15,000 files. So because the preloading.php happens before the server starts accepting requests, you see that the more files you put in there, the longer it takes for the server to actually boot. And if you do only the hot classes, the overhead isn't that much. Same for the memory. You see that we're only almost using 105 megabytes of memory to load all the classes that we don't even, that we're not even using. And then if you have a look at the request per seconds, you can see that the hot class preloading is the way to go. Beside the fact that this is a very active topic and there's a lot of contributions, they're not really eager to start doing it. So you're welcome to keep the discussion here as a central point, but to be clear, I'm fairly confident that in the near future we are not going to add anything to composure. And if any year or so it turns out that there's something composure is uniquely positioned to really help with this preloading, then we can have another look. But for now we see that it depends on your deployment, it depends on your application. A lot of more research about the actual performance improvements have to be done. So there were some issues in the beginning. So the RSC talked about opcache compile file and then you have to figure out the object graph or the inheritance yourself. So the Laravel and the symphony just took a file and they used auto-loading. So they did require. So the auto-loading automatically knew what files it had to include. But they more focused on the opcache compile file way than the require. So in the beginning there were a lot of segfolds but most of that has been fixed. And there are some issues in the bug tracker but it's not that bad. I think the previous version, the previous minor version, disabled preloading by default for Windows because Windows and memory does some crazy things. So yeah, about performance. Is it worth the effort of using preloading? Well, it depends on the situation. So you have to figure it out. Also you have to make, you know your application the best. You know your application the best to know what files are really important for your application, what files that you want to have there immediately. So yeah, stick with the hot classes. Don't put everything into memory. And from a hosting perspective, we're now looking how we can do that, how we can use all the information and start suggesting preloading files for customers. Even try to figure out the hot classes and then automatically adding a preload file for them and then see if we see improvements. So yeah, even if it's a small improvement, if you have a lot of accounts like we do, we see a lot of improvements on the cluster overall. So if you want to see some more reports, a lot of people are actually using preloading. The results are mixed. So if you saw the results from the composer outputs, that's from like half a year ago, that were very promising. The real life improvements are, yeah, they vary. So some preloading resources, we have the internals email, we have the preloading RSC where you can still find most of the information and go out about preloading. And then we have the pull request if you really want to see how they did it and see have a look at the pull request. So in conclusion, about PSP performance, know enough about the PSP internals, how does op-cache work, how does all the loading works. Know how your application works and that depends a lot. So use the op-cache status to get real-time information about your application if you have restarts, if you do use a lot of memory and stuff. If you then take that information, fine-tune your settings and then most importantly, repeat because if you double the memory because your op-cache is full and you have a huge application, you could have another full memory and you'd have to reiterate. So make sure that you keep inspecting your performance. So one last point, what we do at Combal, we have an elastic stack and we gather for all our customers, we gather all the data, so we have all the real-part op-cache statistics and we shove it all into elastic so that we can see what we can do about it. Like I said, it's changing constantly so you have to repeat it a lot. So we keep monitoring and if we see that size are full, we try to implement auto-tuning so that we can increase memory, decrease memory so that we can even drop the loads on our systems and then we're trying to figure out if we can do stuff with preloading and auto-configure preloading and that concludes my presentation. Thank you very much.


I think one of the things, and we talked about COVID, it's a personal impact to me, but other people as well. One of the things that people are craving right now is information, factual information, truth, tech truth as we call it. But here, this event for us, Dave, is our first inaugural editorial event, Rob, Bo, Kristen, Nicole, the entire CUBE team, SiliconANGLE, really trying to put together more of a cadence. We're going to do more of these events where we can put out and feature the best people in our community that have great, fresh voices. You know, we do interview the big names, Andy Jassy, Michael Dell, the billionaires, the people making things happen, but it's often the people under them that are the real newsmakers. If you look at the architecture of our cloud data centers, the single most important invention was Scaleout. Scaleout of identical or near identical servers all connected to a standard IP Ethernet network. That's the architecture. Now, the building blocks of this architecture is Ethernet switches, which make up the network, IP Ethernet switches, and then the servers are all built using general purpose x86 CPUs with DRAM, with SSD, with hard drives all connected inside the CPU. Now, the fact that you scale these server nodes as they're called out was very, very important in addressing the problem of how do you build very large scale infrastructure using general purpose compute. But this architecture is a compute-centric architecture, and the reason it's a compute-centric architecture is if you open this server node, what you see is a connection to the network, typically with a simple network interface card, and then you have CPUs, which are in the middle of the action. Not only are the CPUs processing the application workload, but they're processing all of the IO workload, what we call data-centric workload. And so when you connect SSDs and hard drives and GPUs and everything to the CPU, as well as to the network, you can now imagine that the CPU is doing two functions. It's running the applications, but it's also playing traffic cop for the IO. So every IO has to go to the CPU and you're executing instructions typically in the operating system and you're interrupting the CPU many, many millions of times a second. Now, general purpose CPUs and the architecture of these CPUs was never designed to play traffic cop because the traffic cop function is a function that requires you to be interrupted very, very frequently. So it's critical that in this new architecture where there's a lot of data, a lot of e-stress traffic, the percentage of workload, which is data-centric has gone from maybe one to 2% to 30 to 40%. The path to innovation is paved by data. If you don't have data, you don't have machine learning. You don't have the next generation of analytics applications that helps you chart a path forward into a world that seems to be changing every week. And so in order to have that insight, in order to have that predictive forecasting that every company needs regardless of what industry that you're in today, it all starts from data. And I think the key shift that I've seen is how customers are thinking about that data about being instantly usable. Whereas in the past, it might have been a backup, now it's part of a data lake. And if you can bring that data into a data lake, you can have not just analytics or machine learning or auditing applications, it's really what does your application do for your business and how can it take advantage of that vast amount of shared data set in your business? We are actually moving towards decentralization. If we think today, like let's move data aside, if we said the only way web would work, the only way we get access to various applications on the web or pages is to centralize it, we would laugh at that idea. But for some reason, we don't question that when it comes to data, right? So I think it's time to embrace the complexity that comes with the growth of number of sources, the proliferation of sources and consumptions models, embrace the distribution of sources of data that they're not just within one part of organization, they're not just within even bounds of organization, they're beyond the bounds of organization. And then look back and say, okay, if that's the trend of our industry in general, given the fabric of computation and data that we put in globally in place, then how the architecture and technology and organizational structure incentives need to move to embrace that complexity. And to me, that requires a paradigm shift, a full stack from how we organize our organizations, how we organize our teams, how we put a technology in place to look at it from a decentralized angle. I actually think we're in the midst of the transition to what's called distributed cloud, where if you look at modernized cloud apps today, they're actually made up of services from different clouds and also distributed edge locations. And that's going to have a pretty profound impact in the way we build apps. We wake up every day worrying about our customer and worrying about the customer condition and to absolutely make sure we deliver the best in the first attempt that we do. So when you take the plethora of products we've delivered in Azure, be it Azure SQL, be it Azure Cosmos DB, Synapse, Azure Databricks, which we did in partnership with Databricks, Azure Machine Learning. And recently, when we sort of offered the world's first comprehensive data governance solution in Azure Purview, I would humbly submit to you that we are leading the way. How important are rankings within the Google Cloud team or are you focused mainly more on growth and just consistency? No, I don't think, again, I'm not worried about, we are not focused on ranking or any of that stuff typically. I think we're worried about making sure customers are satisfied and we're adding more and more customers. So if you look at the volume of customers we are signing up, a lot of the large deals we're doing, if you look at the announcement we had made over the last year, has been tremendous momentum around that. You know, the thing that is really interesting about where we have been versus where we're going is we spent a lot of time talking about virtualizing hardware and moving that around and what does that look like? And creating that as more of a software paradigm. And the thing we're talking about now is what does cloud as an operating model look like? What is the manageability of that? What is the security of that? What, you know, we've talked a lot about containers and moving into different, you know, dev sec ops and all those different trends that we've been talking about like now we're doing them. So we've only gotten to the first crank of that. And I think every technology vendor we talked to now has to address, how are they going to do a highly distributed management and security landscape? Like what are they going to layer on top of that? Because it's not just about, oh, I've taken a rack of something sort of a storage compute and virtualized it. I now have to create a new operating model around it. In a way, we're almost redoing what the OSI stack looks like and what the software and solutions are for that. And the whole idea of, you know, we in every recession we make things smaller. You know, in 91 we said we're going to go away from mainframes into Unix servers and we made the unit of compute smaller. Then in the year 2000, when there was the next bubble burst and the recession afterwards, we moved from Unix servers to Windows and Intel, x86 and eventually Linux as well. Again, we made things smaller, going from million dollar servers to $5,000 servers, shorter libs servers. And that's what we did in 2008, 2009. I said, look, we don't even need to buy servers. We can do things with virtual machines, which are servers that are an incarnation in the digital world. There's nothing in the physical world that actually even lives. But we made it even smaller. And now with cloud in the last three, four years and what will happen in the coming decade, they're going to make it even smaller, not just in space, which is size, you know, with functions and containers and virtual machines, but also in time. So I think the right way to think about edge is where can you reasonably process the data? And it obviously makes sense to process data at the first opportunity you have, but much data is encrypted between the original device, say, and the application. And so edge as a place doesn't make as much sense as edge as an opportunity to decrypt and analyze data in the clear. When I think of shift left, I think of that Mobius that we all look at all of the time in how we deliver and like plan, write code, deliver software, and then manage it, monitor it, right? Like that entire DevOps workflow. And today, when we think about where security lives, it either is a blocker to deploying production or most commonly, it lives long after code has been deployed to production. And there's a security team constantly playing catch up, trying to ensure that the development team, whose job is to deliver value to their customers quickly, right, deploy as fast as we can as many great customer facing features. They're then looking at it months after software has been deployed and then hurrying and trying to assess where the bugs are and trying to get that information back to software developers so that they can fix those issues. Shifting left to me means software engineers are finding those bugs as they're writing code or in the CI CD pipeline, long before code has been deployed to production. Doing this for quite a while now, it still comes down to the people. I can get the technology to do what it needs to do as long as I have the right requirements. So that goes back to people, making sure you have the partnership that goes back to leadership in the people. And then the change management aspects, right out of the gate, you should be worrying about how this change is going to be, how it's going to affect and then the adoption and engagement because adoption is critical because you can go create the best thing you think from a technology perspective, but if it doesn't get used correctly, it's not worth the investment. So I agree, whether it digital transformation or innovation, it still comes down to understanding the business model and injecting and utilizing technology to grow or reduce costs, grow the business or reduce costs.


Live from Silicon Valley, it's theCUBE, covering Mobile World Congress 2017, brought to you by Intel. Okay, welcome back everyone. We are here live in Palo Alto for theCUBE's special coverage of Mobile World Congress 2017. We're in our new 4,500 square foot studio. Just moved in, we'll be expanding. You'll see a lot more in-studio coverage from theCUBE as well as our normal going out to the events and extracting the signals from the noise. I'm John Furrier. I'm Jeff Frick, general manager of theCUBE. But a breakdown, all the action. As you know, we do a lot of data science. We've been watching the grid. We've been on the treadmill all weekend, all last week, digging into the Mobile World Congress, sentiment the vibe, the direction, and trying to synthesize all the action and really kind of bring it all together for everyone here. And of course we're doing it in Palo Alto. We're going to bring folks in from Silicon Valley that could not have made the trek to Barcelona. We're going to be talking to folks on the phone who are in Barcelona. You heard from Lynn Kahn from Intel. We have Floyd coming up next, CTO at SAP. We're going to be breaking down all the action from their new cloud and big Apple news. SAP now has a general availability of the iOS native development kit which should change the game for SAP. There is tons of smart cities, smart stadiums, you know, IoT, autonomous vehicles, so much going on at Mobile World Congress. We're going to break that down every day starting at 8 a.m. in-studio. And of course want to thank Intel for headlining our sponsorship and allowing us to create this great content with some contributing support from SAP Clouds.  Check out their booth, check out their coverage, and check out the new SAP Cloud that's been renamed from HANA Cloud to SAP Clouds without their support. We wouldn't be able to bring this wall-to-wall great commentary. Jeff, so with that aside, we've got two days. We've got Laura Cooney coming in, Bob Stafansky managing this bridge between Detroit and Silicon Valley and all that great stuff. The phones are ringing off the hook here in the studio. Go tweet us, by the way, at theCUBE or at Furrier. We have Guy Churchwood coming in. We have great content all week.  Really going to break down the changing aspect of Mobile World Congress. It's the iPhone's 10 years old. We're seeing now a new step function of disruption. Peter Burris, head of research at Wikibon, said the most turbulent time. And I even compounded it worse by saying, and the phones are getting faster. So it's beyond the device. I mean, what are you seeing on the grid? You look at the data out there. John, a bunch of things as we've been watching, kind of the stream of the data that came in and surprised me. First off, just a lot of early announcements around BlackBerry and Nokia who are often not really mentioned as the leaders in the handset space. Not a place that we cover real extensively, but really kind of these guys making a move and really trying to take advantage of the void that Samsung left with some of the note issues. But what I thought was even more interesting is on our hashtag monitoring tools that IoT and 5G are actually above any of the handset manufacturers. So it really supports a hypothesis that we have that while handsets will be better and there'll be more data enabled by 5G, what 5G is really all about is an IoT enabler and really another huge step in the direction of connected devices, autonomous vehicles. You've talked about it. We cover IoT a lot, but I thought that was pretty interesting. Well, the RoboCar is also in there. That's a hash and tag. Well, I love the car. Future, future. Well, it's kind of a symbol of the future of the car which, again, ties it all together. Right, right. Well, yeah, the driverless race car, which is pretty interesting. He sports to a whole other level. Yeah, I thought that was interesting. Another little thing as we watched these digital assistants and these voice assistants, John, and I got a couple for Christmas just so I could try them out is that Motorola announced that they were going to partner with Alexa and use the Alexa voice system inside of their phones. You know, I'm still waiting for, I don't know why Siri doesn't have a standalone device. And really when you use a Google Home versus Amazon Alexa, very different devices, really different kind of targets. So I thought that was an interesting announcement that also came out. But fundamentally, it's just, it's fun to see the support of IoT and 5G and really enable this next kind of great wave of distribution, disruption and opportunity. We're going to have Sar Goli in the studio later today and tomorrow as a guest analyst for us on theCUBE. Of course, for folks who may know Sar from being on theCUBE, he was recently a senior vice president reported to Meg Whitman and built out that telco service provider, NFV business model for HP. And he's been to Mobile World Conference almost every year. He didn't make it this year. He'll be coming in studio. And he told me prior to me extremely vetting him for theCUBE, if you will, to use a Trump term, after extreme vetting of Sar Goli, I said to him, he really wants to make the point of, and this is going to be critical analysis and kind of poking a hole into the hype, which is he doesn't think that the technology's ready for prime time. And specifically, he's going to comment around, he doesn't believe that the apps are ready for all this bandwidth. He doesn't think, he thinks that 5G is a solution looking for a problem. And I don't necessarily agree with him. So we have a nice commentary. So we'll look for SAR today on theCUBE at the 1130s coming on. So it's going to be a little cage match there with SAR. So... I always go back to the Amara's law, which again, I think is the most underrepresented and most impactful law, which is probably in the short term in the hype cycle, 5G is probably not going to deliver on the promise up to the level of the hype. But as we find over and over with these funny things like Bluetooth, who would ever like Bluetooth? Would be such an integral part of so many things that we do today. I think over the long term, the midterm, I think the opportunities is giant. I mean, I think for people to understand 5G at least the way I was described it over the weekend when I was at my, out of the cross games and soccer games over the weekend is the folks that are in tech. 5G is the holy grail for IoT, mobile cars and AI because what 5G does, it creates that mesh of RF or RF radio frequency at a whole new level. You look at the radios that Intel is announcing across their telco partners and what Intel is doing really is a game changer and we all know LTE when the signal is low on the phone everyone freaks out. We all know when Wi-Fi doesn't work the world kind of comes to a crawl. I mean, you just think 15 years ago Wi-Fi wasn't even around. So now think about the impact of just what we rely on with the digital plumbing called wireless. You think about the impact of going around the fiber to the home and the cost it takes to bring fiber to the Lincomp was commenting on that. So having this massively scalable bandwidth that's a radio frequency wireless is just a game changer and if you do low latency, 10, 20 gig, that's all you need. Then you're going to start to see the phones change and the apps change and as Peter Burr said a turbulent change of value propositions will emerge. It's funny at RSA a couple weeks back that the chatter was people at RSA they don't use Wi-Fi. They rely on secure mobile networks and so 5G is going to enable that even more. And as you said, if you can get that fat bandwidth to your phone in a safer and secure, more trusted way what is the impacts on Wi-Fi and what we've come to expect on our devices and the responsiveness. And all that said, there will be new devices. There will be new capabilities. And I guess the other thing is kind of funny is that of course the Oscars made their way up on the board. I thought that might wipe everything out after last night, but no IoT and 5G is still above Oscars on the trending hashtag. I mean Oscars brings up, you know, it's funny. I mean, we all watched the Oscars, the SNF who I think it was still game, it was some sort of ploy but again, you bring up entertainment with the Oscars. You look at what Hollywood's going through and the Hollywood reporter had an article talking about Reed Hastings with Netflix. He talked today. I thought about 4K and really kind of higher end, you know, videos. So the entertainment business is shifting. The cord cutting is happening. We're seeing more and more what they call over the top and this is the opportunity for the service providers but also for the entertainment industry. And with social media and with all these new form factors changing, the role of media will be a packet data game and how much can you fit in there? Whether it's eSports to feature filmmaking, the game is certainly changing and again, I think Mobile World Congress is changing so radically. It's not just a device show anymore. It's not about the handset. It's about what the enablement is and I think that's why the 5G impact is interesting and then making it all work together because a car, talking to this device, it's complicated. So there's got to be the glue. There's all kinds of new opportunities and that's what I'm intrigued by the Intel Qualcomm situation where you got two chip guys battling it out for who's going to be that glue layer under the hood. Right and a lot of the, if you look at some of the quotes coming out of the show too, a lot of the kind of high level threats you got to get away from the components and get into the systems and solutions which we hear about over and over and over again. It's always about systems and solutions. I think they will find a problem to solve with the 5G, I think it's out there but it is, you know, you have to get away from the components. It's an ecosystem play, right?  Give me more bandwidth. I will consume more bandwidth. I mean, look at compute power as an example. People thought Moore's law was going to cap out, you know, decade ago. You look at the compute power in the chips and with the cloud, with Amazon and the cloud providers. It's almost infinite compute so then the role of data comes in. So now you got data, now you got mobile. So I think give us more bandwidth. I think the apps have no problem leveling up. Sucking it up well. It's going to be the debate with Sargalite. So we'll see what he has to say. Like the old chip, right? The Intel Microsoft thing where, you know, Microsoft or Intel would come out with a faster chip then the OS, we eat up more of it as part of the OS and it kept going and going. But I think, you know, we talk to a lot of VCs, John and if you're trying to predict the future and building for the future, you really have to plan now for almost infinite bandwidth for free, infinite storage for free, infinite compute for free. And while those curves are, you know, kind of asymptotically approaching free, they're not there yet. That is really the world in which we're heading and how do you reshape the way you design apps, experiences, interfaces without those constraints, which before were so, so significant. I'm just doing a little crowd chat here. Go to crowdchat.net slash MWC. If you want to leave news links or check in with the folks chatting. And I'm just talking to SAP and SAP had the big Apple news. And one of the things that's interesting in Peter Burris talked about this on our opening this morning is that confluence between the consumer business and then the infrastructure's happening. And that is what's called DevOps, but now you're starting to see the developers really focusing on the business value of technology. But yet it's not all developers, even though people are saying, oh, the developers are the new king makers. Well, I would say that, but the business model still is driven by the apps. And I think developers are certainly closer to the front lines, but I think you're going to start to see a much more tighter coupling between the C level folks in business and the developers. It's not just going to be a developer led 100% direction. So whether it's entertainment, roll of data, that's going to be pretty interesting, Jeff. So Apple's just about finished building the new spaceship headquarters, right? I think it opens up next month. I'm just curious to get your take, John, on Apple. I mean, obviously the iPhone changed the game 10 years ago. What's the next big card that Apple's going to play? Cause they seem to have, you know, kind of settled down. You know, they're not at the top of the headlines anymore. Well, from my sources that Apple, there are many and deep inside at the highest levels. What I'm hearing is the following. Obviously they're doing extremely well financially. Look at the retail, look at the breadth of business. I think Tim Cook has done an amazing job and to all my peers and pundits who are trashing Apple, they just really don't know what they're talking about. Apple's dominating at many levels. They're dominating firstly on the fiscal performance of the company. Their digital presence in terms of their stickiness is second to none. However, Apple does have to stay on their game because you look at Huawei and all the phone guys, they are in essence copying Apple. So I think Apple is going to be very, very fine. I think where they could really double down and win on is what they did by getting out of the car business. I think that was super smart. There was a post by Autoblog this weekend saying Silicon Valley failed. I completely disagree with that statement. Although in the short term, it looks like on the scoreboard, they're kind of tapping out although Tesla is here, as well as a bunch of other companies. But it's not about making the car anymore. It's all about the car's role in a bigger digital ecosystem. So to me, I think Apple has poised beautifully to use their financial muscle to either buy car companies or deal with the digital aspect of it and bring that lifestyle to the car where the digital services for the personalization of the user will be the sticking point for the transportation. So I think Apple has poised beautifully for that. They have some issues, certainly every company does, but compared to everyone else, I just see no one even close to Apple at the financial level, just with the cash and then just what they're doing with the tech. So from a digital perspective, now Google's got the self-driving cars, Facebook's a thread, Amazon, so those are the big ones I see. Now the other thing that's happening this week is the game developer conference in San Francisco at Moscone. So again, huge consumers of bandwidth, huge consumers of compute power, not so much storage. I mean, I haven't heard much kind of of the confluence of the 5G movement with the game developer conference, but clearly that's going to have a huge impact as most gaming is probably going to move to more and more mobile platform-less desktop. Well, the game developer conference, the one that's going on the GDC, is kind of has a different vibe right now. It's losing, it's a little bit lackluster in my mind. It's classic conference, it's very monetized. The event seems to be over-monetized. It's all about making money rather than promoting community. The community in gaming is shifting. So if you look at like how that show is run versus say E3 and now you got TwitchCon and then Mobile World Congress, one of the big voices is no eSports conversation. That certainly will be the big thing. To me, everything that's going digital around gaming is a home run. I think gaming is going to shift in a huge way from what we know as console, cult, it's going to go completely mainstream in all aspects of the devices. As 5G overlays on top of the networks with the software, gaming will be the first pop. You're going to see eSports goes nuclear, TwitchCon, those kinds of Twitch genres are going to expand and certainly the cube will have in the future a gaming cube. So there'll be a cube, anchor desk for most of the gaming culture. Certainly younger hosts are going to come on. We're going to be planning on that. But to me, I think the gaming thing is going to be much more lifestyle, less culty. I think the game developer conference has lost its edge. Right, and one of the other things that comes is obviously Samsung made a huge push. They're advertising crazy last night on the Oscars with the Casey Neistat ad about the people are creating movies. And they've had their VR product out for a while. But there's a lot of social activity saying what is going to be the killer app that kind of breaks through VR? We know Oculus has had some issues. What are you kind of reading between the tea leaves there, John? Well, it's interesting the Oscars was awesome last night. I was loved to watch the Hollywood spectacle. But one of the things that I liked was that segment where they introduced the technical Oscars and they kind of were tongue and cheek is the no one in Hollywood really has any clue and they were pandering. Well, we didn't even know what they meant, but it was really the alpha geeks who were pioneering what used to be the green screen technology. Now you go in CGI, it's our world. I mean, I'm like, yeah, I want to see that more of that because that is going to be the future Hollywood. The tools and the technologies for filmmaking is going to have a Moore's law like impact. It's the same I was mentioning about eSports. You're going to see all kinds of new creative. You're going to see all kinds of new tech. They talked about these new cameras. I'm like, do a whole show on that and we'd love it. But what it's going to enable is you're going to see CGI come down to the price point where what we look at PowerPoints and Adobe Creative Suite and these tools, you're going to start to see some badass creative come down for CGI. And this is where the artist aspect comes in. I think art design will be a killer field. I think that is going to be the future of filmmaking. I think you're going to see an indie market explode in terms of talent. The new voices are going to emerge. The whole diversity thing is going to go away because now you're going to have a complete disruption of Hollywood where Hollywood owns it all. That's going to get flattened down. I think you're going to see a massive democratization of filmmaking. That's my take. And then of course we just continue to watch the big players. The big players are in here. It's the startups that provide the spice, but I'm looking here at the Ford SAP announcement that came across the wire. We know Ford's coming in at scale. GM has done a lot of stuff with IBM as well. So those people bring massive scale and scale as we know drives pricing. And I think when people like to cap on Moore's Law, they're so focused on the physical. I think the power of Moore's Law has nothing to do with the microprocessor per se. It did early days, but really it's an attitude, which we talked about a little bit briefly about what does the world look like if you have infinite networking, infinite compute and infinite storage at basically free. And if you start to think that way, that changes your perspective on everything. All right, Jeff, well thanks for the commentary. Great segment, really breaking down the impact of Mobile World Congress. Again, this show is morphing from a device show, phone show to a full-on end-to-end network, companies like Intel are leading the way and the entire ecosystem of industry partners are going to write software for this whole new app craze, Mobile World, of course. We'll be covering it here all day today, Monday the 27th and all day the 28th.  We've got more guests coming right back with more after this short break.


I've actually put the club in the bag that I have never had in all the years I've been playing. This is such a huge change to my current setup. This is how I change my golf clubs to find more confidence in the most difficult part of the golf bag. If you find hitting anything longer than a five iron, a challenge then this video is certainly for you. The longer the shaft and the stronger the lofts is a combination that can result in problems for many golfers and if you don't make the right choices you're always going to struggle. Quite simply if you don't generate enough club head speed then you have an unavoidable problem and I have my own solution but it could also help you. So two new golf clubs have made their way into my bag but there is also the addition of a third which quite honestly I just didn't see coming. And the first new club that I've put in my bag I have never carried in all the years that I've played golf. How good is that? I don't think I've ever hit three continually three shots as good off that tee and all of them did something different. So the first new club in my bag is in fact a forward. Never had one before and why is it included now? Well for a long time now I've been suggesting that most average golfers drop a three wood out of their bag. Strong lofted, long shaft, limited use in terms of flexibility on a golf course and quite often they become a cobweb collector. Now I swapped into a five wood but that also presented me with a few problems which the forward resolves. So the question really was could I find a club that had enough loft on it that would give me confidence to play from the fairway, from the roof and from the tee that produced better performance than a five wood and the answer was a forward. Now forward is lofted at 17 degrees it's adjustable so I can do things with it anyway but that one degree of difference between that and the sort of standard five wood meant a huge difference because it gave me just a much more penetrating ball flight off the tee which perhaps I didn't get with the five. It's only a minor tweak and a minor difference but it sits really nice as a secondary club if I'm not playing too good with driver off the tee then I've got an option that I can go to that would normally be for a lot of golfers a three wood but then that's it whereas with this as you can see I can play it off a tight lie on the fairway and I can still play it from the roof as well so it doesn't become another cobweb, cobweb collector. So that's the explanation for a forward fairly simple and now a four hybrid another club that hasn't made it into my bag before and why did they go with that? Well quite simply the longest iron in my bag currently is a five iron why is that well that's important as well and simply a what I was finding from Trackman numbers is a six, a five and a four iron but almost traveling the same distance and that's due to very similar clubbed speed to me not generating enough to get that ball launching with those stronger lofts so I moved into a four hybrid it's got plenty of loft what you've seen so far as it pops the ball up very nice indeed it's very easy to play so it's an obvious choice to make the game a whole lot easier it's as simple as that stop at five iron I'm comfortable there four iron no longer needed let's get straight into a four hybrid it plugs a gap yardage wise but it also stacks loads of possibilities and versatility in a bag because that's the key factor in this video it's all about making a game a little bit easier and putting a bag together that works for you but there was one club that made it into my bag it defied all logic it came as a huge shock to me and likely to you as well now there's many reasons to why this came as a shock to me first of all it's strong lofted it's a strong lofted iron and I first of all didn't think I would be able to generate the clubbed speed to make this thing work it is in fact a new drive-in iron from PXG 18 degrees is that loft it's an absolute rocket launcher it's phone-filled hollow bodied forged iron very much like the rest of the setup and as you can see there's a bit of meat on that sole and all-round it's a type of club that I like to use but all that I have tried in the past I've struggled with a little bit inconsistencies this thing is very different and it fits perfectly in my bag I should leave that camera on you know I never seem to miss a port when it's on the driving iron is clearly not for everybody and I think that's important to note but it's important to get your bag and a whole message of this video is get the bag that works for you and what this club does for me is it fits a gap in the bag that can become very sort of cluttered and confused it's mainly to do with the ball flight and the spin and it gives me a lot of options when I'm playing either from the tee or from the fairway and it's not something that I currently have covered right we're taking a bit of a quick cover under the brawly what I want to talk you about is why I've got three clubs in the bag and well maybe two do very very similar things in terms of the distance they carry but are in the bag for very different reasons first of all the forward travel the longest as you can see on this fairway if it was during the summer that would bound on and that gap would become longer between the three tee shots but the other two are the ones of interest they've got a four hybrid which essentially carries the same distance almost as the driving iron but they carry there in a very different way the four hybrid is a much higher launching ball it'll have greater spin and when playing downwind in this situation it's perfectly fine the driving iron on the other hand is a much lower ball flight as you can see lower spinning model and where that becomes different certainly playing links golf and why it's in the bag right now is if that wind is against us then I've got an option to play and that's a much lower flighted ball than that of the four hybrid so it's important that you've got clubs in your bag for logical reasons and that essentially is why two clubs carry the same distance but do things very very different indeed so although these three clubs all work for me in terms of yardages and carry distances there's one key other elements that you cannot forget and that's confidence because if you step on the tee and the club you have an an petrified you when it's time to stick that one on eBay that confidence thing is absolutely huge and surprisingly I'm loving this thing and really haven't missed a fair way today the point is this very simply if you've got clubs in the bag that only work say one in five times then that really does defy logic you've got to pick clubs that work for you and not against you and I'm comfortable with the changes that I've made our three additions which I really am first of all very confident with and after that it's all down to your own personal performance and seeing what you can get out on today's been a good day anyway thanks for watching thanks to Walsy Golf Club for having us it started off pretty grim it's finished off not too bad and we've ended up with one down the middle on the 18th see you next week


Secretary of the Navy Ray Mabes announced several new Department of the Navy personnel initiatives May 13th. He described these initiatives which include easy body fat restrictions, boosting career flexibility and pushing to recruit more women in the Navy and the Marine Corps. USS Pittsburgh is home after a six month deployment to the US-European Command Area of Responsibility. During the cruise, Pittsburgh steamed more than 30,000 nautical miles in support of maritime security operations while supporting national security interests. USS Fort Worth, you recently completed a week-long routine patrol in the South China Sea. The patrol marked the first time an LCS has operated in international waters near the Spratly Islands. And finally, Secretary of Defense Ashton Carter announced his nomination of Admiral John Richardson as the next Chief of Naval Operation. Richardson is a career submarine officer and the current Director of Naval Nuclear Propulsion Program. For these stories and more, visit Navy.mil.


The time has come for you to contribute towards getting the world back to normalcy. Your opportunity to extinguish the pandemic is here. The COVID vaccination drive has begun. Taking everything into consideration, we at Manipal Hospital Whitefield have initiated a hassle-free COVID vaccination drive. The procedure and protocols one has to go through are easy to follow and the entire process is seamless.  Government of India, State Government of Karnataka has done an amazing job in terms of making the entire vaccination program so successful. The vaccination program has started for the people who are beyond 60 years of age. We also kept a window open for the people who are 45 to 60 years with some comorbid conditions. Today we have started the COVID vaccination program and many of you may have many doubts whether to take it or not. I request you please take it. It is a very safe vaccine. Already in India, more than 1.6 crore people have taken it. All of us in the hospital we have taken, it's very safe. I request you to take this vaccine, join the fight against COVID and get vaccinated. Once you have registered yourself on the government portal and arrive at our hospital on your appointment date, your details will be verified. For senior citizens, we also assist in registering yourself on the government portals. But the vaccination slot for that day would be subject to availability. You will enter the vaccination room in turns. Getting vaccinated today is like getting insured and safeguarding your future against the COVID pandemic. Once you are vaccinated, you will spend 30 minutes in the observation room where we take time and effort to ensure that the vaccine has no side effects on your body. Post which you may leave the hospital. My name is Pooja Kanoga. I have taken the vaccination today and it was absolutely painless and had no problem even after taking the vaccination. My mother-in-law was 84 years old. Even she has taken and she is absolutely fine and the experience is just too good. Remember, taking the COVID vaccine must not be an uncertain option but a smart and deliberate choice to create a healthy tomorrow. Our country has made an incredible achievement in making this avenue available to extinguish the pandemic. And now it's your turn to do your bit. Contribute towards healthy humanity. Get vaccinated.