At PacketZoom we collect billions of performance metrics from our users across the world every month. We use these data points to constantly improve our protocol-based service. In addition to that, we use this data to pupulate our customer dashboards to show speed increases, percent of rescued transfers, network packet-loss and other various useful data.
Our customers love all of this fine grained performance info that's not readily available to them elsewhere. So then we started thinking, why not make all this information available to everyone? Free of cost!!
One of our previous blog posts about android http libraries gained quite a bit of an interest from developer community. Encouraged we thought it might be a good idea to expand it more into in-depth series of posts on networking performance.
Today, we at PacketZoom are proud to release our open source tool LogZoom,
a fast, lightweight, and reliable log data indexer written in Go. If you've
ever considered using Logstash, Fluentd, or some other tool for log
aggregation, you may want to consider using LogZoom instead.
Here are a number of resources for getting up and running with LogZoom:
It’s that time of year again, GDC is this week in San Francisco and PacketZoom will be there! I’m very excited that PacketZoom is co-sponsoring the F2P Forum Mixer on Wednesday (http://bit.ly/1P4Rky4), so come by and see us! We’ll be able to tell you all about our tech and how it will help your mobile game.
Read more ...
Network latency and packet loss are inherent in mobile networks. To see what users experience in reality, many mobile network simulator tools allow you to test your app in different network conditions. So you’ve seen your app perform beautifully in the perfect network in your office, but what about in slow networks? Here's an obvious statement: different mobile networks around the world exhibit different behavior. Network type (LTE, 3G, 2G etc) is one of the most obvious differences that can affect an app, but not everyone has realized that the impact that network has on a mobile app is something that can (and should) be tested.
Super Bowl 50 is almost here in our own backyard and today we found out that our proposed superbowl commercial was rejected. I'm sure that this must be one of those situations where you have to know the right people to get in, but I think our bid of $54.27 was very reasonable. Check out the videos we had hoped to run below:
Read more ...
Last week there was some pretty big news in the mobile app developer community: Facebook is shutting down Parse. While giving the community who rely on Parse a whole year to find an alternative is a nice gesture from the Facebook/Parse team, it still sucks. Your choices are pretty straight forward: Find an alternative and rebuild your app, or host your own instance of the Parse Server on your own infrastructure. Part of what made Parse so great was that you didn't have to worry about your server side. Now, along with figuring out how to make you app work in a world without Parse (Yikes!), you have to worry about dealing with how your app will scale if usage starts to grow(double Yikes).
In part I of this series we illustrated some cases of how you can measure throughput for a single file transfer and for requests that happen in series. We also discussed examples of transfers with parallel requests that should (and do) have the same throughput, but our calculations showed vastly different throughput numbers for different level of parallelism. This is because parallelism makes it complicated to measure the actual throughput achieved by the channel. While measuring throughput for serial transfers is straightforward using a method to calculate weighted averages, parallel transfers are typically measured in isolation by commonly used tools, which produce misleading results. So how should you go about measuring throughput for a mobile app?
If your application has downloadable content and you care about how fast that content is getting delivered to your users, you should accurately measure the throughput seen by your app. Now, this sounds pretty simple in principle. Just take the amount of data transferred and divide it by the time taken. While that principle is true, putting it into practice can be surprisingly tricky when multiple parallel transfers are involved. We'll walk through some examples and try to develop an intuition for the complications involved.