We are a production performance management company, but pretty much done with it. And my presentation today would be related to MongoDB performance tuning and load testing. So MongoDB is pretty much very well most of the people aware. It's one of the databases that kind of rise a couple years ago. And it's a rival very closely related to the arrival of the cloud and cheap commodity hardware. And with MongoDB, as well as other databases like Cassandra, CouchDB, or Hadoop, what we allow to do, we allow to do very fast scaling of the system. And also those databases providing us ability to not to use SQL. The user open notation, which is no SQL. In some of the cases, it's JSON or BSON, like in MongoDB. In some cases, it's ability to use MapReduce, which is kind of a way to distribute the jobs, make a big processing of data, combine them together. So MongoDB becomes, since then, since last couple years, become very actively used in a large enterprise environments. Companies like Shutterfly use it to store terabytes of data, petabytes of data, and petabytes of data. Companies like eBay becoming one of the largest users in the world of MongoDB, as well as Adobe, which I was personally involved in helping Adobe actually to scale MongoDB. It was a very challenging project, especially a couple years ago when the cloud was, AWS cloud was very basic and very unoptimal. So it was a challenge setting up EBS volumes, finding out that IO really not working, and finding out the proper ways to scale, especially when IO become very sensitive part of MongoDB. And it is still unfortunately very sensitive. So this is kind of a thing. So from the point of agenda, what I want to accomplish today is to provide some overall overview of what can be done with the performance tuning, what can be done with the load testing of MongoDB. And ladies and gentlemen, if I may ask, what kind of background do we have in MongoDB? It's like intermediate, advanced, so I would know the level of the audience. So again, the idea to show general things. And one of the important things is today, like installing MongoDB, it's basically a joke. If you have your own system, you go, you download VMware image.  And in a couple minutes, you can have it running. Another couple minutes, you can set up replica and have all those things done. So it's a very simple process, but really the thought should come is how to scale MongoDB when it goes into production environment. And prior to the recent version, like 2.2, prior version, they had big issues related to the single right locking and all those things. And they're working on this, of course. Now they make a database level, and they're joking probably another five years, they maybe would make it to the normal level like a normal database. It's actually would be a low-level locking. But right now, the best we can get from them, it's a database-level locking. So we see that there is issues with the rise in the production. Also, another issue, and this is a little bit more over the scope of this presentation, but also there's lots of issues related to sharding because we have memory map files. You have basically fragmentation there if collection's not being managed properly. And then when you have a shard, you can have a really big issues when suddenly the balancers start doing crazy activity and brings the system down. So you have to be very careful about this. And this is why what's really important is to perform kind of decomposition of your production system. You really need to understand, of course, to begin with what business users trying to achieve where it would be the main right activity. What would be the frequency of operation? This is all given and important. But when you start deploying this into production, you really need to look into, okay, how do I configure my servers? How do I configure my IO? How do I configure my scaling? Do I need replication across collocations? Would I have a Venn-level issues basically going across different zones, for example, and all those things which comes very important in production implementation? And load testing, this is another area which is very important because at the end of the day, we can theorize and we can see it to work, it would not work. But at the end of the day, we have major activity. When we're trying to upgrade the system, we need to know the system would be stable under production load. When we're trying to change some parameter and see if it makes sense, it would improve performance, it all comes back to the load testing. And this is also very important, it's very important to create a sandbox environment in your place where you can actually test this and test this under the load, which would be very close to real production activity. This is absolutely must have. Again, going through the areas, we can deal with the operating system tuning layer. Not too much there, but still can be, some things can be tuned. Storage tuning, then database level tuning and load testing. And of course, there is a lot of things can be done on the storage tuning. There's a lot of things can be done on database tuning and load testing. Obviously, there's lots of approaches which we can explore. So, OST tuning, one area which is given again from the point of the manual, there is a U limits document in the MongoDB manual, you can go there. It will tell you specifically what U limits you want to set for the production implementation. In other areas, there is some production nodes document which also stakes. Like for example, they want you to turn off the time tracking on the file system. They don't want to use those huge pages. And one of the important things, if you have like multiple nodes in the system, like replicated or shard, they want you to use an NTP to synchronize timing between them. So this is kind of a given stuff. Another thing which is very helpful, and I'm not sure if we can see there, but this is a tuned utility. So this is a part of like a red hat, you can install it. It's just you install tuned. And what it does, it's an adaptive system for automatic system tuning. So I wouldn't propagate to use it in the production environment, because it may end up unpleasant surprise. Maybe if you're desperate, you can do it. But what I would definitely tell you to do is to go to your load testing environment. And while you're simulating production load, execute tuned. Tuned has multiple, I don't think again, unfortunately it's not showing here, but it has multiple profiles. Which you can say I want to tune for high throughput and I want to tune for minimum latency, all kind of things. So it has a default profiles which you can use.  So I'll definitely recommend using tuned. It's a good approach. Again, in the load testing environment, it's a great tool to use. And again, I can provide information. So if gentlemen you need any, if you need any help during your test, give me a call or write me an email. I would be glad to help you and please share what I know on this. Then the area of the storage tuning coming in. And storage tuning is the most critical in MongoDB. Unfortunately, MongoDB is still very sensitive towards right performance, your performance. It has journaling, it has its own right, it does f-things, paging becoming a big issue. So one of the things that is becoming kind of a common knowledge, like you need to go with the rate 10. So basically Stripe and Mirror. Mirror and Stripe. Then from the point of file systems, you can use EXT4 which is I recommend personally or you can go and do the XFS. And there is also another reason to use EXT4 because it's the next slide. It's actually they find out some really good performance optimization related to EXT4 which is external journaling on the file system level. So another thing which I can say is like, put a good effort to optimize your IO because you can delay sharding. Sharding can be very painful, it increases complexity, it decreases reliability of your system in general. So yeah, if you have huge system that you know by business requirement, you will require sharding because of the huge amount of IO you have to process. Like let's say you can process like 400 IOs per second versus you need to be able to do like a couple of thousands IOs per second. You may be diverted to sharding to begin with, but if you don't have to do it, just try to optimize the IO and not jump to sharding immediately. Another area which was used successfully at Shutterfly and at Shutterfly I just know the gentleman who worked together at eBay, it's Kenny Gorman. He one of the top no skill guys. So they tested flash cache, they got a very good results. So this is the one option that you can consider, combining SSD with the flash cache. And if you have to be on AWS, that absolutely I recommend to go to provision diops and make sure that you have enough capacity. The regular just standard diops wouldn't work really well in production load. Another very good study which get a very good result and actually share some view here. It's using XTFS plus external journal on SSD, which gives a really, really good IO results. Of course, you need to test it in your environment. They recommend to use journal as thing commit. The full study is located on Australian side, but if you can see that they're actually coming in and saying that if this is would be, if this would be a general like performance after we change those options put it on basically external SSD journal on XT4. It basically was 4x, like four times difference in IO performance. So it's a really good basically approach to tune IO without going like pure SSD because it's maybe expensive. So if you can just put this journal on SSD, this can provide a really good leverage on IO performance. So I definitely strongly recommend you to test it and validate it for your environment, but it gives very good results. So another study which I found worth it to share, it's a company like software layer acquired by IBM. They did their extensive study, the URL is here. But they find out some interesting things like obviously like two first points. They kind of self-obvious like when a working data set is smaller than available memory query performance would be better, obviously. The number of clients performing queries has an impact on query performance because more data is being cached given. But the other two studies is very important because what they find out that if you create a separate mount point for a journal, it gives you immediately good performance boost which is a good way to do. And then the best deployment in the terms of operations per second. They find out that if you go basically separate rate 10 SSD data mount and rate one on journal. So it gives you a good leverage on IO and I definitely encourage you to go and read the whole study. It has a great data. It has a great benchmarking information. It can be very helpful when you need to evaluate for performance. And again, I personally myself, I believe in the benchmarking and believe in the load testing because this is the only way to understand how the system would be performing in your own environment. The next way, like a general way, okay. So we need one of these things which is very important. You need to have a very strong handle on performance of your back end operating system. It's something that can give you a really good clue, something was happening wrong even before you're diving into the database performance. So general things like Linux utilities, make sure you run them. IO start, VM start, MP start, SAR, this is a standard test. To see that like a cached information like it's free dash tm, it's a good command to do this. From the point of availability of the system, just a general monitoring, use standard stuff like Nagios Cacti, they're available. I put couple links with the default plugins and profiles. Like I like personally Cacti because it collects data, enables historical analysis. And one of the recommendations that they definitely, maybe it's not very standard, but I am a big proponent of the Oracle Oath Watcher. Oracle Oath Watcher, it's a free utility, which if you Oracle shop, or have Oracle, or have Oracle DBA friend, you can download the stuff. I don't think there's any license associated with it or something you have to pay for it. Oath Watcher, it's automatic collector, which collects automatically data and archives it. It collects data across operating system, IO, kernel level information, like a kernel parameter changes, top processes, processes, wealth of the amazingly good information. It's already automated, you just do as W start or as W stop. I've seen large enterprises implementing Oath Watcher as a standard across all their systems. I strongly recommend you to use it. It would save you lots of time. They also come with a graphical utility that enables you to charge this data. So again, there's like, I put also a not number if you get access to Oracle support site. This is the Oracle not number which you can use and download this and again install it. So again, strongly recommend it, yes? Usually performance implications with an area of like one, two, three percent of the CPU usage. Of course, if your system under the tremendous load, you may want to change the frequency of the collections. Like default frequency, I think it's like 10 seconds or something like this. But even if there is a big performance overload, I would rather collect the data and find out what was went wrong and fix the problem and make sure it's not happening again versus let it go and then have a random kind of live in the scare that it happened again and don't know again. So yes, absolutely, 24 by 7 collect as a company process. Make sure that it's constantly collected and as soon as we have a problem, it's a flat files, it's a human readable files. You can analyze them. There is a GUI which you can set up the time frame and what you want to generate. And again, I don't want to be a tooting moment horn. We have a software that provides very good analysis for this but it's out of the scope of this presentation. But also watcher definitely strongly recommend to use it. It would remove lots of headaches from you. And the problem with a system like Nagios and Cacti, they're very good and everything is great. They would provide it with a nice chart and notification. As soon as you have a performance spying, the system is CPU bound, IO bound, those tools they just stop working. And you really need to rely on something that was created by people who fighting those problems day after day. So the next thing I just want to do some general overview like a database tuning. So there's lots of parameters in NoSQL and some of them like again something like obvious knowledge like you can, you have to, it's a default disable pre-allocate, basically. You want to pre-allocate space because otherwise when you start in production mode, you don't have pre-allocation if you degrade performance of your system. Another thing which you can look into, it's a journal commit interval. And the default is 100 milliseconds. And again, it's all game between the reliability versus performance. If you monitor the stuff, if you see you constantly, your journal is IO being constantly overloaded, you may even consider, depending of course on the nature of your system, you may consider to extending it to like 300, so it's a topic you can do. But this would decrease the IO load. And again, if your system is in critical situation, it would enable you to survive. If you really care about reliability, then decrease it of course. The minimum is two milliseconds. There is also a couple other options which I wouldn't recommend, but it's there. Like one option for example, you can disable BSON checking. Not a great thing because yeah, it would improve your performance, no question about it, but then if you have a problem, suddenly the driver starts saying you corrupted BSON, you have an issue. And to troubleshoot it, there is another utility which is called MongoSneef, but you don't want to be there. But again, if it's something that critical, you always have an option to do this, but it's a high risk. Another option which you may consider if you had a really tuned environment, you can disable table scans in your environment. So there's another parameter which I also cannot recommend because if you have table scan statement, it would just not fly. So it's a good way if you know and if you have a very good architectural standards and development standard that you know that every collection that being deployed, you have appropriate indexes and everything has to be indexed and yeah, you can put it there. And you say, you know what guys, we have like SLA with our agreement. There should no basically full table scans in our environment, full collection scans in our environment. You deploy it there, it would save you from probably very unpleasant situations going forward, but it may create unpleasant situations and suddenly someone just deployed something and now we need to find out, now we need to put a profiler and by the way, we'll talk, we have a separate page for profiler which is absolutely must have a new environment, but again, you can create a good performance improvement and eliminate unpleasant surprise by disabling table scans. At the same time, you can create unpleasant surprise when having this. In other things you can consider, there is some services which you can potentially disable like HTTP interface if you don't use it, like arrest interface if you don't use it. There is also like a server side JavaScript. If you execute, it's fine. If you don't need it, you can disable it. So it's all again, if you're running production system, if you know you don't use it, then don't. Don't just waste performance. So what database tools MongoDB provides? So the one of the tools that probably everyone using, it's MongoStat. The funny history is again, I'm familiar with the Kenny Gorman who created this tool. Back at eBay, we had a tool which we called the FreeCon, which was doing exactly like this for Oracle database. It's kind of sampling every couple of seconds, giving these lines. So Kenny, a Shutterfly, he got challenged with the performance issues, he wrote it and then he submitted it to MongoDB. The nice thing about MongoStat that it gives you real time performance across important areas. And also if you use an option, dash, dash, discover, it would go across your like chart, replication, basically nodes and you can see it across multiple systems. It provides you with a very good information which you should capture again, my recommendation. Don't just run it when you have a problem. Just run it 24 by seven, log this information. Whenever something bad happens, you want to be in position to go and look into this with your eyes and find out what was going wrong. The information which is important there, for example, like flashes, faults, like flashes basically if you are thinking all the time it's a problem, faults like a page faults, you have a locked database. It's a change basically because right now the locking get moved to the database level. So it's very nice. So you see what percentage of the time is spent on the databases. You have an index misses like when index was not utilized or like a queue of reads or queue of writes. So this information is very important. I strongly recommend to use Mongo Start again, not just a monitoring thing when you have a problem, let's run Mongo Start. No, it's running, it's always there. I have a problem, I look at the log file, I don't look at the Mongo Start. Another utility which is also helpful, not as Mongo Start but it's actually have a good detail on collection level and database level. It actually look at the time spent like a response time spent and you can run it with per collection of your time.  And if you do like dash dash lock option on MongoTOP you can look at the level of the database and time spent and locking. So again, don't just look at this when you have a problem, just log it. And have it forever and it can be very helpful. Again, this is what I'm doing. If you run it and if you see suddenly it consumes lots of resources, maybe it's not a good idea for your site. Again, I don't know your production environment but as a general recommendation, definitely make sure to log this information. And I know personally because I'm DBA, professional DBA of my life, the worst situation was my manager when my manager asking me what's happened and I don't know, let's wait again and log this time. It's not a good way to talk basically. It's always better. You know what, we're collecting this data. If you want us to stop it, we'll stop it, fine. Like if you as a manager want me to stop performance collectors, I'll do it. But it has to be your order, not me, not collecting data. Another area which I found very important is ability to actually analyze data on the network protocol level. So you have two tools here. There is a MongoSNF which is not provided by default. You have to actually source the MongoDB and build it but after you build it, you can use it. So MongoSNF is very important because what it does, it sits on the protocol and it shows you what request, what DSON requests. May I have your attention, please? May I have your attention, please? A fire has been reported in the building. Okay, should we run? Okay. So again, it's database network traffic analysis. The light safety system. The possible arm, do not evacuate. So going back to the presentation, the network traffic analysis. So we have two ways to do this. First is MongoSNF which you have to build yourself against source it. There is instructions, I can share it if you need it but I think they're publicly available. So source the code of the Mongo, there is a scone of MongoSNF, it will build it for you. The good thing, you can run it on production system and it would do some slight performance impact because it would actually analyze the traffic but it's nothing that you usually can really run it on a really highly loaded production system. The nice thing about it is that you can actually capture invalid BSON requests, which is very important. So if you have some issue and by some reason like a driver having a problem or you have some corrupted BSONs and now you really need to understand where they're coming from, you can just run MongoSNF and this is the option dash dash OBG check option. And it would capture those requests which is very important. Another area which I really like in general, for example, we're doing some heavy traffic and we replicate every distributed systems doing all this cross zone activity so we want to really understand what's happening. I recommend strongly to use Wireshark. So Wireshark you can literally capture if you can ask your network administrator if you're basically not cloud environment, you can ask to capture the traffic from the subnet, from the database subnet. So you would have activity of all servers, all clients, everything together. And then first of all, Wireshark, they fully support MongoDB protocol so you can see the request, you can just type MongoDB and it will filter the requests. They don't go down to the BSON level so you have to do it yourself but the main thing, it has lots of analytics inside in Wireshark. You can see the break time of the response times, you can see what requests are doing, you can see the chain of requests. So lots of performance analysis on the Wireshark level, they, especially if suddenly have lots of latency, you need to investigate this latency in the distributed environment, it's extremely helpful. So again, I strongly recommend it's open source, doesn't cost anything so I strongly recommend to use Wireshark. Next thing in the database tuning, this is one thing which is extremely important, it's fragmentation. So what's really happening in MongoDB? MongoDB is using like a memory mapped files and it creates a working set and it has to be in memory and when it's becoming fragmented then basically it takes much more memory, it becomes much less efficient. It also can cause, again, so out of the scope of what I'm covering here but it also can cause lots of sharding issues. It was like big outages happened because of the fragmentation and then improper balancing of the shards. So there is a way to do it, there is like of course, there is a way to defragment on the database level but you can't do it in production. This is why you have a command which you can do compact collection and you can allocate some padding basically for compacting. This is very important and this is one of my strong recommendations. You need to automate your compaction of the collections. There is a link I provided, there is a guy who actually brought a program that you can just use or you can look at his program and write your own but I strongly recommend 24 by seven make sure that you compacting. Otherwise you may have performance issues so it's again some of the recommendations I can definitely share here. It goes for collection level, you have different options, you can provide set of collections, you want to go after them. It would perform but I don't think it would perform like a full scale, like a database level log or something. So it's much lighter and definitely would operate in production. So check this blog, it's really good, it's a recent like from the March of this year. So the guy did a nice work, I look at the code, the code looks solid so I'll definitely recommend to use it. Sorry? No, no, this is a whole nice idea about the script and the approach that you can do it in production. And again, the fragmentation is a big thing so if we can decrease it, it's definitely would benefit performance immediately. I'm sorry? You can look at your basically because the memory mapping so you can look at your like a free activity and if you grow with the time and suddenly you see that your work set is growing then you're getting fragmentation. So in other area, it's obviously a profiler and the things that I strongly recommend and again, it's probably common knowledge like run it with the level one which would capture the slow requests. It has to be 24 by seven again, don't turn it off. You can set as a second parameter there, it's a slow threshold so make it like whatever you consider slow, 100 milliseconds, 200 milliseconds, one second. So put it there. It would return very good output. There is a document which gives exactly profiler information, but the good things again, you can see as when you're running a profiler, you know basically how many documents were scanned, how many were returns. If obviously you're returning one document but scanning 100,000, you have a problem and you need to basically add a proper index, especially if you see this happening all the time and it's the same collection. There is like things if documents were removed, so there's lots of tons of very good statistics. The presentation that Kenny prepared is like relink for presentation. It's a profiler deep dive. It's a good presentation. What he did, he basically get a new aggregation framework and he just plugged it in into the profiler so it can break down the response time, all kind of massaging of the profiler data. So it's definitely something worth looking into and profiler again, you should always run it. Don't do it at level two because it would just log everything so maybe if you just wanna capture some QA workload, at level one is definitely strongly recommended. Next area is indexes. So the thing is with the indexes that developers don't like indexes and they don't appreciate them because they don't care about them. They write code, the code's supposed to return the data. The indexes is falling on DBAs. So there is a way of course to do like explain and when you're just running whatever the statement or whatever you're running on the system, you can always add explain and you can see exactly specifically what would be the scans and if you're scanning too much you can understand if maybe you need a better index, maybe you need a combined index and so on. There is a really good tool which I recommend, it's called DEX or DEX. This tool, what it does, it plugs in into a profiler. It scans all bad queries and it automatically suggests you the proper indexes. So I strongly recommend you to look into DEX and at least when you have a load testing environment or pre-production environment, even in production, if you have some environment which can be just used by ad hoc or some users who can deploy code, hope it's not happening but sometimes it does, you can use DEX and you can capture and get a good indexes automatically. I again recommend not just run it because you like to run it, automate. My kind of main idea is how you survive as a DBA always automate things. So if you automate this, if you can get daily email or alerts that hey, we just find out that this query executed, this request executed so many times and it was really bad and this is the index that we should create, it would make life easier. Then standard UI monitoring. So again, it's common knowledge, there is a MongoDB monitoring service, it's just a chart, you can plug in your database, you can set up your alerts. It's a good software as a service approach. My major complaint, it's very simple, it gives you like a one database, what if I have a cluster, what if I have a shard, what if I have big systems? I want to analyze across them, especially if I'm an enterprise setup and if I have shared storage area network, I really want to be able to be in position to do cross system analysis. So it's a very, very simple thing, so again, it doesn't cost, I think at all or something like this, but it can be used. There is a whole page on MongoDB, there is a bunch of open source software which you can use, I mentioned some of them. By some reasons they don't mention Cacti, which I personally like Cacti and there is a plugin for Cacti exists, so I'll definitely recommend to look into this. Again, the last one, it's tooting my own horn, we basically had a product which deals with MongoDB and does this cross system, cross whatever analysis. The next thing, it's replication. So the major problem is the replication if you have a replication lagging. There's a lot of issues which can cause lagging, it can be like very weak secondary system, just putting on a bad IO, putting on a underpowered node. Another issue is the ride bursting. When you have like a suddenly big amount of rides coming in, you obviously would face some replication lag, building in the indexes, somebody blocking like a secondary for backup, secondary being offline, so those things. How you can measure the lag is to commence, you look at the slave replication info and you look at the replication info and you see pretty much where the lag is, you can calculate it, you can get time difference. On MMS, if you go to the software as a service like monitoring by Tengen, you have a replication lag chart and you can set up alerts. So one of the things that's definitely important, you don't want to be late and especially if you're primary going down, you have a problem. So the slide related to load testing. So first of all, why do we want to put load testing and I put a couple of things, for example, and even for production, not even for application sake. Like we want to validate the upgrades. If we want to move from 2.0 to 2.2, we want to obviously understand if it would be stable under our load. If we're deploying some fixes, same idea. If we're planning for the hardware changes, like we want to change StoryChair network, we want to move to the different node server, we want to maybe consider moving to the cloud or changing the cloud, we need to load test because unless we load test it under real production load, it's a problem and we're just risking the issues happening when we're deploying it into production. Another area is testing the multiples of production load. Okay, great, we're running everything stable. What if tomorrow my company runs marketing promotion and I have like a three X of the load? Can I extend this load or not? It's also a big question. And as much as we can apply capacity theories or the queuing theories or the linear regression, whatever the approach is, it would give you some theoretical numbers. You would never be able to know if suddenly we have a huge basically locking issue because it's happened because some kernel parameters were not set properly. So you never know in reality unless you test it. So what options do we have for the load testing? Not too much options at this point. So first of all, you have a really good product which was written which is called Mongo-perf and make it different. It's not like a Mongo-perf utility of the Mongo. It's a Mongo-perf. So it's kind of a benchmarking tool. I strongly recommend to use it. It's open source, you can build it. It creates kind of a semi TPCC load of this type. You can regulate it, you can change it. But again, strongly recommend to use it. This is as an open source, this is probably your best bet to create a heavy load. There is a four IOLA level testing. There's two utilities you can have. One is Mongo-perf, which is internal utility. It creates kind of a very heavy IOLA level load on the system so you can validate if you can process specific number of IOPS. And usually they require a configuration file and all those things you don't have to do. You can just echo the parameters, pipe it to Mongo-perf and it would take it. The second utility which I strongly recommend to use is IOZone. This is a really good IOLA benchmarking system with a great UI. You can test all kind of level of IO load. You can simulate to your patterns of the load. So check the website. And one of the studies which I showed earlier, that demonstrated why basically XT4 plus SSD level is actually better than a regular approach. It's actually they used IOZone to do this testing. Another option which I can give you a couple of ideas. It's you have a pickup files. Those are the files that you can analyze with a wire shark or you can do with a Mongo sniff. You can capture this traffic and then you can create your own basically tool. And again, if you know how to program, it should not be a very heavy work or if you have some friendly developer who wants to get the protocol offsets and just parse it out and do it. You can create a tool which would do the slow testing which I'm saying production, authentic load testing. So there is a protocol URL which specifically talking about MongoDB wire protocol. So protocol is very simple. Literally like there's some type of operations. You have like a BSON, you can parse BSON, convert it to JSON, whatever you'd like to do. So you can create a custom tool and I strongly again recommend to investigate this approach. If you get a friendly developer, if you want to do it yourself again, this tool would go through the pickup file. It would understand what kind of sockets are used, what are the load basically simulated and then you just have a replay. You generate the normal requests like in Java or in Python, whatever you'd like that can replay it and simulate the production load. And you don't have to capture like a one day of load. It's enough that you know for example through your activities that you have like a one hour of the peak load. So take this one hour of the peak load, use it for your load testing or what you can also do, you can take this one hour of the load, you can split it into chunks that says 30 minutes and then replace them in parallel because your environment is probably homogeneous. It doesn't depend on each other. So it would actually simulate very authentic double load or triple load, whatever you'd like. Again, we currently in the pre-releases of the load testing tool for MongoDB, which does exactly that. So we have it for other databases for Oracle SQL Server and a bunch of others and we adding MongoDB, but approach is very simple, literally. Like our developers created this like parser in a week or something and he was not like a super genius. So just to summarize what I discussed. So it's important to understand the business and environment requirements. So we start with this, understand what business really expects and ask them like a crazy questions. Are you guys planning to like, what's your business goal? Like what would you do in a year? Like I understand right now you want to do this. Do you have projections? Do you have any promotions coming in? Because it's important not to just based on what business is thinking, but also have this vision. Because when system is starting to be loaded, suddenly we have like 20 times more business visitors they're doing so much more transactions and you need to do so many other things. They come to you and think why didn't you scale the system? Why didn't you basically provided the proper capacity? And it's like, yeah, yeah guys, but when we talk, this is what you told me. And still again, they're pointing fingers to us, the DBA. So it's important to say, okay, what's your business vision? What's your goal? Where are you going? It's very important. This is how you would architect your production system. Again, when you're designing a system, always look towards, okay, so I want to be scalable. I want to make sure that this thing is going down. System would still be available.  But if you do not propose it, they would come later to you and tell you why didn't you talk about this? It's so important, why didn't you mention this? And unless you put in front of them, say guys, okay guys, it was your decision not to invest into DR with all due respect. It was your decision not to buy SSD storage. It was your decision not to go with provisioned IOPS and you wanted me to run it on EBS volumes with a default, fine. But you need to put it in front of the business people, make sure that they're buying on the architecture and explain it to them. And one of the things which is very important is implement your monitoring and performance analysis across the layers. Don't, like I mentioned, when you have a performance issue, don't just go say, hey, show me like a server status. It's a cryptic, it has tons of data. Capture this data, run MongoTOP 24 by seven, run Oracle OSWATCHER 24 by seven, run MongoTOP 24 by seven, capture all this data. Whenever something bad happens, you should have a very strong hold on what's happening in the environment. And the last point is, again, put your effort to implement production-like load testing. The protocol structure is open source. It should be a baby task for a normal developer. I know again there is no commercial product at the moment, but you can create it. You can basically get people and they can do it for you. And after you have it, you have a huge leverage because now we can take production traffic. You can simulate the load and you can say, no, guys, you're planning this promotion with a double load system would not holding it. Because I run it, this is a performance metric, this is overload, it's not working. Sorry, we need to bump up the system before you're going basically to X. So this is kind of a summary of my presentation and any questions I would be glad to address. Thank you.


The Power Trading Hour with your host, David White. Call now, toll free at 1-877-927-6648 or internationally at<PHONE_NUMBER>. Now, David White. And welcome all to another excellent edition of the Power Trading Hour. As always, we meet at the appointed time. The following takes place between 2 p.m. and 3 p.m. So we're off a little bit. Is this surprising? The answer is no. We're on the end of fund buying generally on average over the last 20 years. You can look for about a percent and a half higher on average. When it's over, you can look at maybe three quarters of a percent lower as the fund buyers exit. So there's a bullish bias in the last two days, first three days, trading days of the month. When that's over, that bias pulls out a little bit but leaves about half of it. We're off about 7-tenths of a percent right now. So surprising no. Jobs numbers, of course, at 8.30 tomorrow morning. I'll go back into my list of stuff here. And that's it. So really not a lot that's unexpected here. Of course, the question is we pulled back yesterday with very light volume today again. Sorry, another sneeze time out. We've got about 6.3 billion shares. So a very light pullback yet again today. As I said, I don't know, maybe a little weaker in the Friday. I think the thing we need to be looking forward, we don't know what the jobs numbers are going to look like, but we can think about maybe moving in the morning and maybe setting the tone for the day. But the Golden Week being over and traders coming back from China, the question is whether or not they're going to take the bullish tone up that we've had the last few days and maybe add a little bit to it. When I look at a lot of the other things, like I use some wisdom of the crowd indicators that are in my newsletter sometimes, those actually continue to show that we could have yet another good week before any significant pullback in the market. Probably the bigger thing out here that I think is going to affect the market long term or medium, let's call it medium term through the end of the year is OPAC plus production cuts and the decision by the current administration of the United States to double down on taking crude out of the Strategic Petroleum Reserve were down below the levels that we saw in 1978. So we're 24 years in rearview mirror for the lowest amount of reserves we have. The question is at what point could we not field a navy by not having enough reserves and that answer is fairly soon. So we're getting to the point where we would not be able to respond. Now what's to say it's not a military action. Let's say that it's this another hurricane in the Gulf that shuts down 13 of the biggest producing offshore oil wells we have in the country. It's kind of the same thing as planning a trip in an airplane maybe a small airplane. You know it's going to take you three hours to get there and you have three hours and 15 minutes worth of fuel and the winds are kind of in your face a bit maybe they're just a little stronger than you think. All that fuel that you could have put in the plane if it wasn't full doesn't be any good back at the place you took off from. But you want to have at least some kind of pillow for any kind of disruptions and at least probably through all of next year there's no real question about refilling it yet and of course we'll have to refill it where we actually emptied it on an average basis of about $25 per barrel with $85.88 and of course if we start refilling it that could easily take us through 100 or $110 a barrel gas. So I'm going to continue to say that one easy trade going forward is probably going to be energy. There may be some soft spots in the Santa Contango up here where the next month may be still a little soft but as soon as they turn the spickets off and we know there's almost nothing left in the reserves energy may be the easiest trade going forward. 877-9766-4648 we'll have Tim Ord on at the next break and see what else do we have here. Let's do a little history and we'll move on. And it's all just a little bit of history repeating. And somebody says we've got some issues. Everything sounds really good in my headphones so I don't know anything else about that. Okay, let's see. You want to reconnect? Talking to my engineer here now. Sounds awful in the bin. Okay. Getting very static-y. We'll reconnect during the break before I get through this segment here with a little history. And it's all just a little bit of history repeating. On this day in 1942, Chester Carlson's issued a patent on the process called Electro Photography, now commonly known as photocopying. It wasn't until 1946 that a company had any interest in pursuing this commercially. The Halloyd Company, in that bad breath, finally licensed Carlson's patent and created the world's first Xerox photography to differentiate it from the traditional photography. Eventually photocopying became such a large part of the company's revenue that Halloyd changed its name to Xerox. That's good now. Okay, that's great. Who knows? I think a lot of that is just we have temporary issues with internet speeds. And sometimes they just pull back, you never know. Okay, let's see what else here we've got. As we go to the break, we'll have a Tim Ord after it. If you want the charts, make sure and email me at path at tfnn.com. Down, what is that? 25 on the S&P, down 270 and 262 on the Dow. And Aztec off 31. Being inflation, we are purchasing powers eroded. There's no better place to protect your harder and money-thinning gold. VISTA Gold's flagship asset is the Monk Todd Gold Project in the Northern Territory of Australia. This is Australia's largest undeveloped gold project. We are talking a world-class gold project in a tier one mining district. This is a large-scale, low-cost project with significant existing infrastructure in a politically safe and friendly mining jurisdiction. VISTA Gold just completed the Monk Todd Feasibility Study, which resulted in a 7 million-ounce gold reserve in a 16-year mine life. All of this combined with the approvals of all major operational as well as environmental permits. This distinguishes Monk Todd as an attractive, diverse partner, ready-development stage gold project. VISTA Gold trades on the New York Stock Exchange under the symbol VGZ. David White's Trading Newsletter, The Path of Lease Resistance, is delivered daily before the markets open to make every trading day an easy win. Visit TFNN.com today and subscribe to David White's Ultimate Trading Newsletter for $119 a month and try all of our newsletters risk-free with our 30-day money-back guarantee. Take the Path of Lease Resistance at TFNN, Educating Investors. Are you looking for a way to consistently add winning trades to your portfolio? Tom O'Brien is here to help. Tom O'Brien has been successfully trading markets for over 30 years. A frequent contributor to TD Ameritrade Network and CNBC, Tom O'Brien founded TFNN over 20 years ago to help educate investors just like you. Tom's Daily Market Newsletter, Market Insights, is published every morning when the markets open to give you the competitive informational edge you need to succeed. These newsletters are packed full of Tom's advanced technical analysis and are geared to deliver comprehensive strategies for a successful portfolio. Get Tom O'Brien's newsletter, Market Insights, today and try all of our products and newsletters 30 days risk-free with our money-back guarantee at TFNN.com. TFNN, Educating Investors. 7-6-1-8. We return. We want to welcome Tim Ord back on the lines again. Tim Ord has been in the markets for over 40 years. He had a 30-year run already as a newsletter writer. Won several awards for Timer of the Year in many different segments of trading. And we want to welcome him back to the microphones. How are you doing today? Good, good. Thanks for having me on. Can you hear me good? Yeah, a little bit fuzzy, but I guess you're in a hurricane of stuff down there, so can you hear me? Yep, I can hear you fine. I've got chart one up here if you want to get started. All right. How are you dealing with hurricane down there? I don't know. Are you by Tampa? I lost power for about 30 minutes. And that's all? That's about the extent of what happened here in Tampa, at least in my area. I know some people were worse off inland than out here on the area that we're at. But the farther south you went, the bigger the impact. So not much happening. They cleaned up everything, at least in my neck of the woods within and probably 12 hours. And like I said, I think I lost power for 30 or 45 minutes and it came back on and that has been it, the effects. So not much. Good for you. Good for you. Well, it's been a long run since Tampa has actually been hit. It's one of the hardest to hit geographically for a storm. They tend to either hit down there in Fort Myers or in Venice or go up to the Panhandle in Pensacola. It's not that they never hit. It's that if it hits the west coast, it's about one in 10 chance that hits somewhere around Tampa. Always either hits south of us or goes north. So a good place to live if you're looking for a place down here in Florida. Okay. All right. Well, good. Well, take a look at that first chart. It kind of looks at the bigger picture, which is this chart goes back, looks like about 2007. And it's American Association of Individual Investors, Bull Bear Ratio. But it is just a ratio of what the public thinks about the market. Well, actually, it's a pretty good poll that every time it got below 40, we got down in, I think it's like 21 or so here recently, but we're back up to 33, which is still below 40. So in my opinion, we're still kind of banging out a low here. But roughly close to a meaningful low up to that way. This takes an account too of that 2008 decline. And it did get in bullish territory there during that decline. I don't know if we're going to turn in like 2008 or not. I think there is one more decline coming. It'll probably touch at least last Friday's low, maybe break a little bit below it throughly. Finally, get everybody, I guess, out of the market there and we can't, or the market that is, and we can get them out before the rally actually starts. But we're getting close. We're in the process, I think, pounding out a bottom according to chart number one. And I don't know if it's quite complete yet. And it may take another several more weeks to finalize it. But in the past, this is an area that has usually been pretty good for near-me-at-term low forming. So I don't think we're just going to keep heading down and down. I think we're all close to some sort of near-me-at-term low. And I'm not sure we've seen the final low. I've got a couple other charts that I'll show you that maybe we're pounding out a low, but the final low may not have been seen. I do look at some of the indicators. They kind of give you a bigger view of what goes on, what the pre-taught process, what the public is doing. And normally the public's on the wrong side of the market most of the time. So this is an indicator. That kind of suggests that the public's pretty bearish here. And that's usually a good near-me-at-term sign. So we can go on to chart two if you want. Okay. Also, if anybody wants to ask any questions to Tim, make sure and either call us at<PHONE_NUMBER> or email me at pathtfn.com. I already emailed one for you to take a look at during the break, if you want. We've got chart two up here now. Okay. This has really been a good indicator. This chart goes back, I think, to 2015. And the top window is the average arms index on the close for the last 10 days. And the arms index is kind of a screwy, but actually Richard Arms developed it back years ago, in the 70s. And it's the advancing issues divided by the declining issues and divided that by the up volume, divided by the down volume. So it takes in the advanced decline, it takes in the up-down volume and it horses out into a ratio. And so one easy number to look at. You can kind of define what... If you get readings up around 1.5 or higher, in general it shows there's more volume hidden declining issues. When it's down below 0.5, say, then it shows more up volume on the advancing issues. And that's usually a bullish sign. Or ironically, it turns out to be kind of a turning indicator. Because if you get readings around 0.5 several in a day, it shows too much euphoria. And it's usually heading for your client. And the opposite is also concerned, or the opposite is also in play, where it gets up around 1.5 or higher, it shows too many volume on the down stocks. And that's usually kind of a romantic situation. And so going into the June low, we got it above 1.4. And also going into the current low, we got it up to 1.4. So that's 1.4 on average for 10 days. So that's a lot of, you know, I guess hitting the bids there for 10 straight days to really get that reading up that high. So it kind of shows the exhaustion moved to the downside. And those really, those red lines going back show the times when the 10-day average did get above 1.5. So it happened at the March 2020 low. It happened back in the, all right, it's not that good. 2018, there was a worthwhile low in there back in 2015, 2016. And all these, most of them came in really massive lows. So we do have panic in the market and panic only forms at bottom. We'll be back in a minute with Tim and if you want to check your email there, Tim, and if you want these charts, email me at pattyfnn.com. To see for yourself the types of profitable trades that are recommended within the Gold Report, sign up now by visiting tfnn.com. Don't miss out on the next great gold trade. Sign up today. Sharpening your skills as an investor is like getting better at playing a musical instrument. You have to practice, sure, but you also need excellent instruction from experts. At TFNN, you'll get advice and guidance from the authority and technical market analysis, and it's not just dry tedious text either. TFNN airs live financial content streamed live on tfnn.com and TFNN's YouTube channel with Tiger TV, live every market day from 8.30 a.m. to 4.00 p.m. Eastern. For free, each host is an experienced trader and gives their take on the market while taking calls and questions live from around the world. From the moment the market opens until the closing bell sounds, TFNN TV has eight different shows with expert hosts to help you make the right moves with your money. Watch online at tfnn.com or on TFNN's YouTube channel and become the investor you were born to be, TFNN Educating Investors. A piece of software that will complement any trader's methodology. Using this first-of-its-kind program, the Art of Timing the Trade charts allows you to scan thousands of stocks for Fibonacci formation setups, including guardleafs, ABCs, butterflies, and much more. The Art of Timing the Trade charts is designed to help you when scouring the markets for stocks just beginning to form the trading patterns that many investors spend days, weeks, or even months searching to find. And right now, we're offering licenses available at only $79 a month. We are so confident that you're going to love this new charting software that will even give you a 30-day unconditional money-back guarantee. Don't miss out on this incredible new piece of software. Get your copy of the Art of Timing the Trade charts today by visiting TFNN.com. This segment is brought to you by Think or Swim. For more information, just click the Think or Swim banner on the front page of TFNN.com. And we're back with Tim Horde now. And we're looking at chart two. So continue on. Panic. Anything that kind of does with panic, I'm kind of trying zero in on it. That's why VIX, I use quite a bit of stuff with the VIX. And the trend and the techs, I kind of watch all that stuff. The 10-day average of the arms index above 1.4 usually indicates you're starting to bang out and you may have term low. So I don't think this is an extended decline that's going to keep breaking new lows here. I still think we'll probably see a minor new low, but not a major downtrend that started here. It looks like kind of the ending stage. And also, these now, I kind of play as important to it. A lot of times you see major lows in October, maybe November. So I think the lows probably going to, my opinion, probably still form this month. So I'm thinking there's one more down here coming to kind of satisfy everything. So we'll see how it plays out. But anyhow, this is in bullish territory. And we can actually, I did get that email on Exxon Mobile Oil. We can talk about that if you want. Did you send me a chart? Oh, I thought they sent you a chart. I can pop one up. I just wanted to make sure I didn't need to look in email to take a look at it. I've got one up. Okay. If you go back to, you know, it broke out a major basing period. Well, it actually broke above some previous highs. There was a huge resistance at that 70 area on Exxon. And, you know, the election came and they voted in the Democrat party and they were against the, kind of the energy sector. So it took a big, big run down in 20. That turned out to be the bottom and got enough energy to rally above 70. If you look at, actually compare the XOM or Exxon to the SPX, it's been outperforming the SPX since about mid-2020 and it's still outperforming. And I don't, you know, that's worst case scenario. It's got masses supported at 70 because that's the trend line that goes back for years. And I see now we're trying to break out to new highs. I'm not sure we have the volume to really do it right here. The market really hasn't done anything for the last six months and then it's bounced around 285 to 100 range. And the volume is kind of dropping off. It kind of looked like this could be a consolidation phase. In my opinion, then Mark the Halfwood Point move and the Exxon move up. That's a possibility. Not sure what it is, but the Bollinger Bands are mid-Bollinger Bands hitting higher. So in general, it's in an uptrend here. You know, how high is high? It's really kind of hard to say, but it's kind of bucked the, you know, if you look at the decline in the SPX, obviously it's bucked that trend. So it's kind of a trend of its own right now away from the SPX. So this looks pretty good. How high is high? It really is hard to say a lot of projections come if you take the bottom of that pattern, which is around 25 to the top, which is 70, call it 75. So you had 50 points to the breakout area, which is 70. So it comes in around 120 for a projection, a possible project to the next high, which is still, you know, 20% higher than where we are right now. So it doesn't look like it's, in my opinion, doesn't look like it's any topping form, pattern forming here.  So how high is high? You know, I guess projection one is around 120. You can, hey, come up with a bunch of other stuff, but along as it stays above the mid-Bollinger Bands on the wippy timeframe, you know, it's a good indication that this one will probably move much higher. So it looks pretty good, in my opinion, for the earmet term, even longer term. So, you know, that's my take on, on Exxon. Okay, and that was for Hector. So, if you've got a question for Tim, go ahead and email or call in at<PHONE_NUMBER>. Let's go back to the chart here. And on this one, are we done with number two? Yeah, I think we've seen panic in the trend, and it reached a level where earmet term blows normally form. You know, it's not saying the bottom's in right now. I think there's one more decline coming, but it's in a bobbing area. So I think most of the decline is done. But moving on to the next one, which is kind of used this over the years, it's another kind of a climatic indicator. And the top window is NYSE Summation Index. And it's kind of a rule of thumb, I guess, when you get below minus 700, which this chart goes back to, it looks like, about 2015 area. And it kind of shows all the previous declines happened at that time for him. He had a 2016 decline. He had a 2019 decline. He had a March 20th decline. Now you got this one. Actually, if you go to the bottom window, usually a good indication that you're into a war-shot low was a McCall and Offer usually gets below 400. And on September 26th, when he hit minus 420, which pretty much satisfies my climatic move to the downside. And I marked other times there with blue lines that other times when he had below minus 400. So McCall and Offer got below minus 400. And the Summation Index, which is the top window, usually when you get down below minus 700, it's usually a good indication that the market has reached a pretty much sold-out level according to the advanced climb line. And that Summation Index is kind of an exotic advanced climb line is what it is. And I marked other times when that happened on in 2020. Matter of fact, or 2022, we hit below minus 700. This is a third time. So the market really kind of just blew apart to the downside. You know, back in, it was like about April and another time in June and now we're hitting it again in October. So it's pretty oversold. And this time around, finally, the Oscillator, along with the Summation Index, both got below war-shot levels. So we're in a climatic bottom formation here. So it'll be interesting to see what happens next. To really confirm that the intermittent bottom is, you like to see minus 700 on the McCall and the Oscillator, then rally within around two months to reach above plus 1,000. And we tried to get going back in that, or see the August rally. And we didn't quite get to plus 1,000. We got up to plus around 800. Then the market fell back down again and got oversold below minus 700 on the Summation Index. So the next time up, we need to see it get above plus 1,000 to really confirm a low. Well, we've got one more chart and a couple of questions. So we'll get to that in the next segment with Tim Orr. Sharpening your skills as an investor is like getting better at playing a musical instrument. You have to practice, sure, but you also need excellent instruction from experts. At TFNN, you'll get advice and guidance from the authority in technical market analysis. And it's not just dry, tedious text either. TFNN airs live financial content streamed live on TFNN.com and TFNN's YouTube channel with Tiger TV, live every market day from 8.30 a.m. to 4.00 p.m. Eastern for free. Each host is an experienced trader and gives their take on the market while taking calls and questions live from around the world. From the moment the market opens until the closing bell sounds, Tiger TV has eight different shows with expert hosts to help you make the right moves with your money. Watch online at TFNN.com or on TFNN's YouTube channel and become the investor you were born to be, TFNN. Educating investors. The technology around us is changing every day. With so much happening, it can seem impossible to keep up with all the information. David White's investment newsletter, the Technology Insider, is designed to give you all the information you need to understand the technology that shapes today's markets and tomorrow's future. David White has made his living staying on the cutting edge of technology. His weekly newsletter will give you specific recommendations for valued tech stocks, as well as entry prices, target prices, and stops to set for each trade. Dave delivers his weekly newsletters every Friday with updates throughout the week. You can get the Technology Insider at TFNN.com for only $37.50. Sign up for David's newsletter, the Technology Insider, and get an inside look at everything the technology sector has to offer. Try it risk-free today with our 30-day money-back guarantee. TFNN Educating Investors Are China A-Shares hot or not? If you trade China A-Shares, now may be time to take a closer look. Trade C-H-A-U or C-H-A-D. Directions daily, CSI 300, China A-Share, Bull and Bear ETFs. China A-Shares in either direction. Visit DirectionInvestments.com today. An investor should consider the investment objectives, risks, charges, and expenses of the direction shares carefully before investing. The prospectus and summary prospectus contain this and other information about direction shares. To obtain a prospectus or summary prospectus, please contact Direction Shares at<PHONE_NUMBER>. The prospectus or summary prospectus should be read carefully before investing. An investment in the funds is subject to risk, including the possible loss of principal. The funds are designed to be utilized only by sophisticated investors such as traders and active investors. This program is brought to you by Vista Gold, traded on the NYSE American and TSX under the symbol VGZ. As we return, got some questions, we'll answer in a minute after we go through your last chart here, Tim, but we've got a couple of questions on gold, but specifically on GDX. Anyway, back to, are we done with chart three? Do you want to go back to that? No, done with chart three, that's good. Okay. And chart four here. Yeah, it's just kind of a daily chart. I think the character of Mark is starting to change and the reason why I'm saying the character of Mark is kind of a change where the sell signals in the past worked really well and now the buy signals are starting to work pretty well. And it's not ideal yet, but I do a lot of stuff with volume. If you notice that big spike, where I have an open gap there, that big spike in volume is last Friday's trading. So you had a big spike, normally that's kind of exhaust move to the downside. When you get a kind of spike in volume, a lot of times I'll at least stall the market on a short-term basis. I'm talking about a spike in volume. At least 30%, you know, the spike in volume, the more stunned I guess or stalled the market will become in either direction. So if you see a spike in volume say 100%, whatever of the previous days, that usually just stalls the market on a short-term basis. So I'm proud of you. Yeah, it looks like about a 30% jump in volume. And that's kind of a signal that you're probably an exhaust move to the downside. Anyhow, the market gapped up the next day. That would be Monday of this week. And it tested another gap of last Wednesday. Anyhow, it kind of blew through that gap and opened kind of an aisle in there. But when it jumped, this would be today's Thursday, so this would be Wednesday's, no, it would be Tuesday's trading. It jumped above a previous high. And that jump above previous high on at least 10% lighter volume usually is supposed to break out to the upside. Then yesterday, you tested Wednesday's high on another drop of about 10% volume. So the market's really having kind of a difficult time trying to go up here. The volume's not, you know, you're trying to break out above the previous high and then really have the energy to keep pushing higher. But today we're kind of at the midpoint of today's trading. And so the market kind of undecided what to do. It tried to go up, couldn't go up. So I'm thinking when they go back down to Monday's gap is what I'm thinking is what it's starting to look like. And it maybe even breaks a little bit. Normally, the more panic you have at the bottom, the more secure that bottom becomes. So if you get minor panic at the bottom, it's usually a minor low. If you have major panic, it's usually a major bottom. And we had pretty decent panic at last Friday's slow. But if you look at the VIX and some other stuff, it didn't really spike that much. It did get into 34, I think it was, on the VIX. But ideally, you like to really see it jump up around 40 or thereabouts, or a high 30s at least. And I'm thinking that's probably where we're going to head.  And I think that's where you get your durable low coming in. So, you know, that's my short term view of the market. I think in a midterm, we're pounding out a bottom in our short term basis. We may take another shot at the recent lows if not break to a minor new low. And it depends on what the VIX does, what the trend does and some other panic indicators do. So, will that be a final low or not? So, I'm thinking we're off a closer in a midterm low. I just don't quite think we've seen it yet. So, that's my view for the market. So, probably, you know, we may be... market may be mixed all the way into November 8th is the election. Is that right? November 7th? Something like that. I think 40 days away. Yeah. So, market could... maybe that's what's going on here. The market is kind of trying to decide who's going to be... you know, are the Republicans going to hold the house or the Senate and whatever. Are the Democrats going to keep control of it? Don't know. And the market's trying to decide what it is going to do, I guess. So, the market doesn't know yet. But the market will figure it out way before the general public figures it out. You know, the market seems to be the smartest indicator. So, anyhow, it's trying to figure out if a certain party takes over, you know, the Senate or something like that, that would be kind of a readjustment of some of the stocks in the NYSE, whatever, because of different powers that come to power here. So, I think that market is... it could be jittery and too value-election. So, I'm thinking that's what's going on here. Okay, we've got about... I still don't think the term law is counting out here. We've got three minutes left. Any calls on the GDX here? Yeah, I've got a 50-day average of the up-down volume of advanced line indicators. And when you got below my... there's a 50-day average. When you got below minus 20 on both indicators, it's usually led to an in-met term indicator. And what's kind of unusual about those indicators is once it hits below minus 20 on both of them, the market usually trends sideways or even mostly down a little bit for several weeks, while both those indicators hit below minus 20 back in mid-July. And now they're just starting to perform above zero. When it's above zero, usually the market's considered an uptrend. And the market did retrace from that mid-July low until this recent low we had here, what, in late September. So, I'm thinking this rally coming off the low is up, what, six days in a row. And it really showed decent volume come off the low. So, I'm thinking the September 25th low was the bottom. And as long as the 50-day average of the up-down volume and 50-day average of the advanced decline remain nearer zero or above, the uptrend is intact. And right now it's above zero on both of them. So, I'm thinking the bottom was September 25th. So, I'm reading it. So, how high? I don't know. But if you get above the previous low, which is around 29 on GDX, and that would imply a false breakout to the downside of that trading range would imply that you can't hold below the previous lows. They'll try to take out the previous highs. Well, the previous highs is around 40. So, if we get above 30, I think then we're at least heading back to the 40 range. So, that's a fairly near-term, I guess. It could take several weeks or months to do all that. But that's how I'm reading the market. So, I'm thinking we're turning the corner. Okay. I want to thank Tim Orr to the Orr-Oracle for being on again. If you want any of these charts, just email me at pathtfn.com. I'll be glad to send them out to you. So, you can follow along. But that's about it. We'll see Tim in about two more weeks, hopefully, and have a good weekend. All right. Thank you. You bet. VistaGold owns and operates the largest undeveloped gold project in Australia, the Mount Todd Gold Project. VistaGold just completed their feasibility study, resulting in a 7 million-ounce gold reserve. VistaGold has all major permits approved and has retained CIBC capital market assistance in evaluating alternatives and in completing an accretive transaction. VistaGold trades on the NYSE American and TSX under the ticker symbol VGZ. VistaGold executing a strategy to create shareholder value. You might think that if you want to be successful at trading in the stock market, you're going to need a crystal ball. After all, it's impossible to predict the future, right? Like any endeavor in life, before you decide it's impossible, get some advice from the experts. You might find that it's not so impossible after all. For daily market overviews that give you direction on the key indices, selective stocks, and commodities, subscribe to the Opening Call newsletter at tfnn.com. The Opening Call newsletter is written by Basil Chapman, creator of the trading methodology known as the Chapman Wave. The Chapman Wave up-down sequence gives you an edge in identifying price turns, finding the peaks and valleys in stock prices.  First-time subscribers also get a 30-day money-back guarantee. If you're not satisfied, let us know and you'll get a full refund within 30 days of signing up. tfnn.com Educating Investors Everything in the universe is governed by the Fibonacci sequence. This mathematical principle is responsible for everything from the most aesthetically pleasing artwork to patterns in the stock market. To stay on top of stock patterns you can take advantage of, sign up for the Fibonacci 24-7 newsletter at tfnn.com. When you subscribe, you'll get a weekly report from Veteran Day Trader Larry Pesavento on stocks you need to pay attention to and you can trust Larry's analysis. After all, he's got 45 years' experience as a day trader. Larry will also provide daily charts, videos, and data on the key markets that he's tracking. Expect notifications from Larry on market movement you need to act on at any time. First-time subscribers also get a 30-day money-back guarantee. If you're not satisfied, let us know and you'll get a full refund within 30 days of signing up. Subscribe to the Fibonacci 24-7 newsletter today. tfnn.com Educating Investors Available to all Tigers and Tigresses for just $1 for the year. There's no catch or added costs when you join our community of traders.  As we get to finish up the day, starting to see a little bit of a slide. As I said, not uncommon to see maybe about a 1% pullback when fund buying is over. That was, I said in the newsletter, I thought I'd be probably in the first couple of hours this morning. So you get a little bit of that. Probably a little people ringing the register before the jobs numbers in the morning at 8.30. So we'll see. But I don't have any real good feeling on jobs numbers. I continue to think that there's going to be some good sectors and bad sectors. There's always a bull market somewhere. And I'm kind of focusing on energy at the moment, although there are others. But that's kind of it. Volume so far in the day is fairly light. Just doing a little over 7.1 billion shares on the CBOE Consolidated Volume Tape. If you ever want the link to that so you can follow along at home, email me at path at tfnn.com. I'll be glad to send it to you. Other than that, it's just the end of fund buying. Not surprising to see a little bit of a pullback. Tomorrow is probably going to be a much bigger idea. If we get a lot of people shorting probably tonight and maybe get a little bit of surprise, you might find this market holding up through the close tomorrow and into China coming back for those folks that may want to think that they had a fear of missing out of the big rally in the United States. Or at least the U.S. markets. But we shall see. See if there's anything else out here. I was going to say probably the biggest thing I saw that was interesting to me was just the strength of the dollar. Oop, don't have that up right now. And we're out of time. But certainly came off 110 in the DX very sharply. And that's still holding. Well, that's pretty much it. So when you can, not when you have to and we will see you here tomorrow. Same bat channel, same bat time.